database-design - 锁定处理并发——一个好主意？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

4年前关闭。




Improve this question




为了处理并发问题，锁定——任何形式的锁定，无论是行锁定、表锁定还是数据库锁定都是一个好的解决方案？

如果没有，如何处理并发问题？

Answer 1

如果您相信 Oracle，不，完全不相信。这是因为 Oracle 竭尽全力避免它。

问题是读者可以阻塞写者，而写者会阻塞读者，而写者必须等到所有读者都完成了一行之后才能写。这会延迟写入过程及其调用者。排他锁(用于写入)一直保持到事务结束，以防事务必须回滚 - 这会阻止其他事务看到新值，直到事务提交。

在实践中，如果没有太多争用，锁定通常是好的，与任何并发编程一样。如果对行/页/表的争用过多(没有多少数据库服务器执行整个数据库锁定)，则会导致事务依次执行而不是并发执行。

Oracle 使用行版本控制，而不是锁定行来写入它，而是创建该行的新版本。需要重复阅读的读者会记住他们阅读的行的哪个版本。但是，如果记住其读取的读取器尝试更新自此事务读取以来已被另一个写入器更新的行，则会发生错误；这是为了阻止丢失的更新。为了确保你可以更新一行，你必须说 SELECT 是 FOR UPDATE；如果你这样做，它需要一个锁——一次只有一个事务可以保存一行 FOR UPDATE，一个冲突的事务必须等待。

SQL Server 2005 及更高版本支持快照隔离，这是它们对行版本控制的名称。同样，如果您需要更新刚刚读取的某些数据，您应该要求更新锁 - 在 SQL Server 中，使用 WITH (UPDLOCK)。

锁定的另一个问题是死锁的可能性。这只是两个事务各自持有对方需要的资源的锁，或者一般来说，一个事务循环持有对方需要进行的锁。数据库服务器通常会检测到此死锁并终止其中一个事务，将其回滚 - 然后您需要重试该操作。有多个并发事务修改同一行的任何情况都有可能发生死锁。如果以不同的顺序接触行，则会发生死锁；强制执行数据库服务器将使用的顺序非常困难(通常您希望优化器选择最快的顺序，这在不同的查询中不一定保持一致)。

通常我会建议与线程相同 - 使用锁，直到您可以证明它们导致可伸缩性问题，然后找出如何使最关键的部分无锁。