小编Bes*_*ces的帖子

如何在 MySQL 中正确实现乐观锁？

我们的团队推断我们必须执行下面的 #4，否则存在另一个线程可以更新记录的相同版本的风险，但我们想验证这是最好的方法。

1. 在要使用乐观锁定的表上创建一个版本字段，例如 column name = "version"
2. 在选择时，确保包含版本列并记下版本
3. 在对记录进行后续更新时，更新语句应发出“where version = X”，其中 X 是我们在 #2 中收到的版本，并将该更新语句期间的版本字段设置为 X + 1
4. SELECT FOR UPDATE对我们要更新的记录执行 a ，以便我们序列化谁可以对我们尝试更新的记录进行更改。

为了澄清起见，我们试图阻止在同一时间窗口中选择相同记录的两个线程，如果它们同时尝试更新记录，则它们会在其中获取相同版本的记录时相互覆盖。我们相信，除非我们做 #4，否则有可能，如果两个线程同时进入各自的事务（但尚未发布更新），当它们进行更新时，第二个线程将使用 UPDATE ...其中 version = X 将对旧数据进行操作。

即使我们使用版本字段/乐观锁定，我们在更新时也必须执行这种悲观锁定的想法是否正确？

我希望我的 Oracle 数据库能够正确存储所有可能的 UTF8 字符。如果 NLS_CHARSET 设置为 AL32UTF8 就是我需要做的全部吗？或者我是否还需要确保使用 NCHAR 和 NVARCHAR 而不是 CHAR 和 VARCHAR 来正确存储 UTf8 字符？

根据隔离级别，可能会展示 SELECTS 不同行为的场景：

1) 0:00 Thread A runs a query that returns 1000 rows that takes 5 minutes to complete
2) 0:02 Thread B runs a query that returns the same 1000 rows
3) 0:05 Thread A updates the last 1 rows in this result set and commits them
4) 0:07 Thread B's query returns* 

根据隔离级别，#4 中的结果集要么包含线程 A 的更改，要么不包含。UPDATES 也是如此吗？

下面是一个示例场景：

Thread A: UPDATE... set version=6 ... WHERE primary_key = 1234 AND version = 5
Thread B: UPDATE... set …