请高手指点并发问题
服务器配置：64G内存，24核cpu.

后台有30多个线程都在并发处理一个耗时5-10几分钟的sql语句处理数据库数据,每个线程都会隔1分钟执行一次，慢慢导致服务器和数据库很迟钝，有时候数据库直接就挂了，不知道什么原因，难道是数据库支持不了那么多的并发或那么多的耗时并发吗？
望高手解答，并最好给出解决方案。
------解决方案--------------------
1. 这条sql语句执行什么,sql语句复杂吗?关联多少个表?新增\修改\还是删除?具体到某一个表.
2. 操作的表数据量是不是很大,或者是两个大表相关联查询再更新?关联字段是否建了索引,时间久了要重建索引,你先重建索引试看有没有速度提升?
3. 如果建立了索引后还得不到改善,那么就考虑做分区表,多核cpu对分区表的查询或更新就是它的长处,多个cpu可以并行处理事务.
------解决方案--------------------
并发的东西要考虑锁和隔离级别，这个其实是业务需求，不是技术需求。优良的设计可以支持5、6000个并发请求，对于这些操作，第一个要快，不然其他会话需要等待。第二个要尽可能把影响范围缩小，每次都加表锁的话肯定慢。2005以后，分区是比较好的解决并发问题的方案之一。第三个就是用队列——ssb
------解决方案--------------------
同时有30个线程（它们运行在数据库服务器上？）各执行一个5-10分钟的sql？
数据库服务器的cpu始终的100%？
------解决方案--------------------
如果你这个SQL语句是必须执行不可的,建议你另外建立一台服务器,在这台新建服务器上去执行,不要影响原服务器的效率,新建服务器上执行完成以后,先存到本地,然后再定时更新到你的主服务器上去,如果需要实时更新也可以建立2台服务器之间的链接,用新建服务器做为运算服务器,运算完成后,再把数据实时同步过去.
------解决方案--------------------
只有实际分析，并改进（结构或代码或优化流程）性能，是正道
------解决方案--------------------
技术社区里面说，国外的程序写的的程序，最大并行度设为4，效果最好。
而据我在国内的经验，国产“码农”的代码，最大并行度设为1（不使用CPU并行）时效果最好。
所以，楼主还是考虑优化一下代码吧。
------解决方案--------------------

引用:

Quote: 引用:

你可以先尝试建立索引，看看速度能够提高多少

因为数据对插入效率要求很高，每20分钟有几百万数据插入并进行联合处理，如果建立索引会影响插入速度。

每20分钟有几百万数据插入并进行联合处理,你能不能把sql语句帖出来,看看是否可能优化?
我觉得一次性插入几百万,cpu消耗那么多不奇怪,能不能改个方案,每隔两分钟插入十几万数据,或者几十万数据,评估一下二三十万这样平均需要多少时间,这样插入频率高一些,有可能分担cpu的使用率
------解决方案--------------------

引用:

Quote: 引用:

同时有30个线程（它们运行在数据库服务器上？）各执行一个5-10分钟的sql？
数据库服务器的cpu始终的100%？

由于CPU24核，内存也比较大，一般50%

24核的50%，说明12核已经满负荷
长时间持续这么密集的插入，是影响正常运行了
提高硬盘的性能（多硬盘组成阵列或ssd）

这是什么样的应用、背景？
------解决方案--------------------
是不是数据被锁了，这样就会导致死锁。
------解决方案--------------------

引用:

是不是数据被锁了，这样就会导致死锁。

死锁不会导致cpu高吧
------解决方案--------------------
你的问题是需要你自己进行平衡的，现在你不建索引，确实是插入速度快，但是查询速度非常慢。

我原来的公司，接近1.5一条数据的表和另一个几千万数据的表进行关联，语句非常复杂，都是接近10个表的管关联，通过建立索引，每次运行，都可以控制在20秒以内，但如果不建索引的话，10分钟都运行不完，还好是报表，不是定时任务，要是定时任务的话，在本次定时任务没运行完，一会就又触发下一次定时任务，那么数据库积压了N多个语句要运行，再强的服务器也得歇菜，数据库肯定得崩溃，那台服务器也就是32G的内存，8个核心线程，性能方面和你的服务器没办法比的。

你上面说每20分钟会有一批几百万的数据插入，我觉得通过大批量插入技术，应该是非常快的，我在公司另一台服务器试过，插入几十万条数据，也就20秒左右，那服务器的性能是很一般的。


通过建立索引，当然啦，插入速度会下降一点，但由此在查询方面取得的性能提升，让数据库不再崩溃，这才是最重要的。

这个还是得加强测试，调优。


------解决方案--------------------
bcp、bulk insert 都能处理大数据量插入，如果是相对静态的库，还可以先切换恢复模式，同时如果表有分区，那理论上还能加快插入的速度
------解决方案--------------------
select into的速度其实也不低了。几百万数据查到一个临时表我试过少于10秒就完成了
------解决方案--------------------

引用:

Quote: 引用:

你的问题是需要你自己进行平衡的，现在你不建索引，确实是插入速度快，但是查询速度非常慢。

我