我什么时候应该关注交易规模？

Question

我有一个功能，我们需要合并用户记录。用户选择要保留的用户和要丢弃的用户。

我们在数据库中有59个与用户记录的关系，因此对于我需要做的每一个：

UPDATE (Table) set UserNo=(userToKeep) WHERE UserNo=(userToDiscard)

然后删除userToDiscard及其用户首选项（118）。

我应该担心交易规模吗？这是MS-SQL 2005。

我能做些什么吗？

由于

Answer 1

您是否测试过程实际需要多长时间？用户多久合并一次？

如果你对每个表中的用户ID都有索引（我认为这是自然而然的事情），那么即使有59个表，执行这些更新和删除也不会花费太长时间。如果你实际上每周只合并几次用户，那么这样的一点点不应该是一个问题。在最坏的情况下，有人必须等待额外的几秒钟才能每周做一到两次。

另一种选择是将这些用户合并请求保存在表格中，并在夜间过程中（或者每当“非工作时间”用于您的应用程序时）进行实际工作。虽然合并不会立即生效，但您需要向应用程序的用户明确说明。您还需要考虑很多可能的意外情况：如果同一个用户设置为当晚与两个不同的用户合并，等等。

Answer 2

这取决于您的用户表的大小以及您拥有的索引。

Answer 3

合并用户听起来不像经常使用的功能。鉴于此，有98％的可能性你不应该担心交易规模（为可能的死锁保留2％）

Answer 4

通常，事务应该是最小化争用和可能的死锁情况所需的最小规模。 （尽管使它们太小也会导致开销）如果某些行首先更改而其他行稍后更改，那么针对这些表的查询是否会产生错误的结果？根据您的应用程序，这可能会导致业务问题。

知道每张表中会更新多少行？如果每个用户在表中有数百万行，则可能需要比每个表中有少量行更加小心。