表锁引发异常与表锁等待结束

Sybase 和 MsSql 共享相同的历史代码库。 回到过去（sql 2000 之前）和同一时代的 Sybase。 两家供应商都没有解决锁定问题。 他们每个人都可能陷入死锁状态。 问题是他们使用的逻辑。 想象一下死锁情况，例如在 4 路停车处驾驶汽车。 想象一下，如果规则说当两个记录（汽车）同时进入时向右让步。 这工作正常，除非有 4 辆车同时到达，每辆车都试图让路给右侧的汽车。 你得到一个僵局的情况。 过去，DBA 必须选择一个记录来终止该事务（阻止其完成）以允许死锁清除。 后来，MsSql 实现了自动选择要杀死的记录的逻辑。 他们还改进了锁定逻辑，因此死锁在未来版本中的频率要低得多。 因此，有时它有效，有时它不起作用是由您的记录被选择终止的记录还是其他死锁完成以处理您的记录所驱动的。

Oracle 做更好的锁定逻辑。 它们保留给定字段的多个副本，具体取决于多个进程是否同时修改它。 当您执行选择时，您将获得已提交的记录，这些记录在运行未完成进程的不久内运行 Sybase/MsSql 锁定方案等待完成。 后来的MsSql版本比Sql 7和sql 2000做得更好，这是一个更大的问题。 Sybase可能也经历了同样的改进。

有一些方法可以通过将大表分解为较小的表并从较小的表批量更新到较大的表来减少此锁定问题。 可以把它想象成一个左右桌子。 当您执行高容量插入活动左侧表时，右侧表将插入到主表中。 然后，您切换并向右侧表执行大量插入操作，同时将左侧表移动到主表。 这将分解表之间的事务，并减少多个进程同时访问同一表的机会（减少死锁）。 但这意味着您没有最新的数据，因为您在左右表中处理的记录不完整。