我有以下情况：
多个程序访问（更新，删除，插入和选择）的表。实际上它们是相同的，但是由多个用户实例化。由于程序在使用后删除数据并再次插入新数据，因此该表永远不会增长到1000行以上。这就像是供应商/收集者的情况。
由于这是一个工业生产场景，我必须保证一些操作，因此当用户确认任何操作时，程序会使用来自系统上其他表的数据更新该表。
所以我们在很多命令上实现了事务。结果是很多死锁情况。
我想要一些关于我们可以做些什么以避免这些锁的提示。实际上我们不需要事务，我们只需要保证命令将运行，如果由于任何原因它失败，整个操作就会回滚。我不知道在没有使用交易的情况下是否有办法做到这一点。
PS：我们正在使用SQL Server 2008 R2。
PS2：我发现在更新中FROM子句中使用的一些系统表是个大问题。这些表用于整个系统，并获得大量的插入/更新/选择。所以我只是锁定了不应该的东西，因为我没有用这个程序更改那些表上的数据。
EX：
Update t1
set x= 1
from systable1 as t
inner join systable2 t2
where .....
我想这是个大问题，所以我在t和t2上添加了提示WITH (NOLOCK)，在t1上添加了WITH (ROWLOCK)。
其他事情我必须提到，这是一个测试环境，我们在最大限度地强调数据库和程序，因为我们不能冒生产失败的风险。
如果失败，我可以使用检查点策略重新执行操作吗？
感谢。
答案 0 :(得分：0)
您可以使用READ UNCOMMITTED消除锁定问题（请参阅Why use a READ UNCOMMITTED isolation level?和http://msdn.microsoft.com/en-us/library/aa259216(v=sql.80).aspx）。但请注意，这可能会导致读取数据不一致或不一定会持久存储在数据库中。
答案 1 :(得分：0)
使用readuncommitted是一种可能的解决方案，虽然它具有连锁效应。我先尝试一下rowlock。 SQL Server优化到页面锁定以减少记录上的锁定数量，因为除非它们非常宽，否则只有一千条记录，页面锁定将锁定很少的记录。
答案 2 :(得分：0)
首先调整Transaction中的所有查询。有时通过添加索引来加速对事务内部的查询可能会对您看到的死锁数量产生很大影响。
此外，保持事务尽可能小，以实现在出现故障时所需的回滚。例如，如果您有5个查询数据，但只有3个查询数据，那么您可以将事务缩减到只有3个更改数据的查询。
希望这有帮助。
答案 3 :(得分：0)
首先，是的，您需要事务来确保成功或失败（回滚）。只有1000条记录？该表必须受到插入/更新/删除的攻击！所以对我来说这听起来像一个繁重的事务表 - 所以要小心添加索引，因为它们只会使你的插入/更新/删除更慢。我必须确认你的繁重交易表上没有触发器，对吧？
那你的读书怎么样？有没有考虑过分离报告表或什么？复制可能有点过分。数据需要多准确和最新？
最后 - 个人资料，个人资料，个人资料。