特别是对于SQL Server，您可能希望更改数据库以启用READ_COMMITTED_SHAPSHOT。
这基本上可以防止在数据上有待处理的插入/更新时，您的选择查询被锁定。
一些需要关注的问题：
1) 你的插入/更新或选择查询是否属于事务的一部分？如果是，确保为您的特定情况设置了最有利的事务隔离级别。
2) 这个巨大的表上是否有太多的索引？索引可以加速选择，但会减慢插入和更新。确保只使用必要的索引。
3) 与＃2有关。您是否缺少将加速选择的索引？您的选择语句是否正在进行全表扫描？查看查询执行计划以了解实际情况。（查询分析器可以协助您）。
4) 考虑将巨大的数据复制到一个或多个只读数据库服务器中，这些服务器可以处理选择流量，而读/写主表（即现有表）主要处理插入/更新流量。
5) 您的插入/更新操作是否触发了触发器，可能会导致性能或锁定问题？
6) 您的应用程序是否遇到死锁事务？请查看此MSDN文章并查看它是否有所帮助。此外，请确保您了解哲学家就餐问题，以避免死锁事务。
如果您使用的是企业版，则最理想的解决方案是使用滑动窗口分区。基本上，您需要在相同的文件组上创建一个相同的表，将数据加载到该表中，然后“切换”该表的分区到生产表中。实际操作只是元数据翻转，所以它几乎瞬间完成。请查看这里获取更多信息：http://technet.microsoft.com/en-us/library/ms191160.aspx
如果您只需要从Web应用程序中的表中读取数据，则可能希望尝试使用READ_UNCOMMITTED隔离级别进行查询。它不会锁定任何内容并读取未提交的数据。我不建议在银行应用程序等方面这样做，但大多数典型的业务Web应用程序可能不会有问题。确保在查询后将隔离级别设置回您通常使用的级别（READ COMMITTED？）。
如果对于您来说使用READ_UNCOMMITTED不可行，则可以熟悉基于行版本控制的隔离级别。例如，快照隔离使用乐观的方法来修改数据，从而减少了对行的悲观锁定的需求。
