大量数据又死锁了该如何处理

Question

    大家好，先说说我之前的一个经历，前个月网站突然卡死报数据库连接超时错误，甚至从界面上无法登录数据库，还必须以dos命令 net stop mssqlserver, 然后net start mssqlserver来重启数据库，好那么一下又卡死了，我用的是2005，数据库主要数据文件达到1.39G， 服务器2003。当卡的时候，我用 exec sp_who_lock 命令无查看死锁和堵塞，一运行一大堆的死锁和堵塞，看到都吓人，最后弄清楚了，是因为我的创建索引过多，在数据插入修改的时候效率极低，导致的，结果我适当删除了一些索引就没事啦，由此可见当报死锁的时候，并不一定是提示死锁的存储过程的问题，而且其他问题导致的死锁堵塞的大排队。
    可过了一个多月，现在又出现了死锁，我又适当删除了一些索引，并且把每个表都重建索引了（  DBCC DBREINDEX(数据库名..表名,'',0)每个表都以这样的方式重建索引    ），死锁依然时而出现，这个时候我就不知道该怎么办了，因为我的数据库有几个表都几十万数据，有一个表一百多万，都是插入和查询比较平凡的表，为不会是因为数据量大导致的死锁呢？
几十万的数据会至于导致死锁吗？
    如果是因为数据量大的原因，那么有什么好办法吗？我考虑过分表，比如把去年一年的数据存在到另一张结构相同的表， 但是这样的改动，在查询的时候很不方便。 有没有什么更好的办法吗？ 
    我的表主键都是guid类型，默认主键聚集索引，我改成非聚集的，因为让物理存储顺序按guid列排序，应该是效率很低的，所以我的表基本上没有聚集索引，但我会根据查询的排序字段适当创建非聚集索引， 会不会是这个原因呢？

Answer 1

不重要的查询使用脏读select .... from yourtable (nolock)

Answer 2

  一： SQL查询优化一下，查询时where 后的语句要和索引里的顺序对应，你在用索引想必应该是优化过这方面的。
  二：还有定期重新生成索引，索引在使用一段时间后会有碎片。
  三：建立表分区。
  四：用SQL的性能分析功具找出哪些查询或是写入比较查资源，然后再找解决办法。一般来说一个表超过30万条数据就要小心了。

Answer 3

可以把表用年份或月份来创建数据，程序要注意此方式读取，类似分区概念，当然sql2008是有分区功能的

Answer 4

才不到2G的数据库就要“分表”？你是靠删除大量索引来“解决”死锁问题？什么是死锁（难道报告异常“数据库连接超时错误”就叫做死锁）？无语。我们每个月做少增加30G数据的时候，也没有为数据库分表呢。堆砌一大堆名词，我看不出你的问题。不过只是给你一个建议，好好看看应用程序连接和使用数据库方面有没有程序bug、流程设计问题，不要盯着数据库表。

Answer 5

不用聚集索引，效率太低了吧？特别是分页的时候。
另外建议采用中间层缓存查询结果，不要频繁的访问数据库，同时使用一个好的ORM框架。

Answer 6

用脏读 select  with (nolock)
这个肯定是由于在程序上设计的问题,减少表的关联性,缩小表的字段数量,分离不需要经常访问的字段到其他表.尽量少用表关联.

Answer 7

  超时不是索引的问题。你只要建个作业定期清理索引碎片。。 应该跟你写的查询语句， 和你的数据操作层应该有问题去优化下。。  查询尽量用contains查询吧    另外可以使用点缓存。。

Answer 8

with nolock 会改善很多。

Answer 9

可以偿试用分区表
SQL Server分区表