我有一张包含281,433条记录的表格，范围从2010年3月到当前日期（2014年9月）。它是一个交易表，由确定当前进出仓库的库存的记录组成。
当从仓库中挑选时，系统需要查看来自特定客户的每笔交易（根据确定客户的AccountListID字段，客户平均可能在表中有大约300条记录） ）。在完成拣配运行时，每个特定.NET应用程序的请求会发生2-3次。
有时候数据库似乎已经锁定了。有些请求在3秒内完成。其他人则需要长达4分钟的时间。根据最终用户。
我的猜测是同时有4-5个请求所有查看这个事务表的事情都被锁定了。
我正考虑对此表进行分区，以便主要事务表仅包含过去2年的记录。最终用户同意不需要在此日期之后的任何记录。
但我不能删除它们，它们会在系统的其他地方使用。我已经建立了索引并且它们产生了巨大的差异（从> 30秒到＆lt; 2，在accountlistid字段上）。似乎分区是下一步。
1）我是否采取正确的方式解决我的锁定问题？问题？ 2）当移动一组记录（例如，字段DateTimeCheckedIn超过2年的记录）这是一个手动过程还是分区自动执行此操作？
答案 0 :(得分：2)
对于行少于300,000的表，不需要进行分区，除非每条记录都很大。如果一条记录占用超过4k字节，那么你有300,000页（2,400,000,000字节），并且它会变得更大。
索引通常是这样的解决方案。花费一秒多的时间在索引数据库中返回300条记录似乎需要很长时间（除非记录非常大并且网络开销增加了时间）。您的表和索引都应该适合内存。检查你的内存配置。
下一个问题是应用程序代码。如果它使用游标，那么这些可能是在某些情况下锁定行的罪魁祸首。对于只读游标，“FAST_FORWARD”或“FORWARD READ_ONLY”应该很快。如果应用程序代码锁定 all 历史记录，则可能会出现争用。毕竟，当两个记录（针对不同的）客户位于同一数据页上时，会发生这种情况。解决方案是在读取历史记录时不锁定它们。或者，避免一起使用游标。
答案 1 :(得分：1)
我认为这里不需要分区。你可以通过一个位置合理的索引解决这个问题：我正在考虑一个单一的索引（按顺序）覆盖公司，部件号和数量。或者，如果它是旧服务器，可能只需添加ram。最后，因为这是为事务读取大量旧数据，其中单个事务本身可能永远（或者至多很少）一旦写入就更新了，您可能会在此查询的READ UNCOMMITTED隔离级别上做得更好。