我问这个问题有点愚蠢，但是为了弄清楚事情，有时必须问一些愚蠢的问题：）
因此，我们可以像马丁·克莱普曼（Martin Kleppmann）在演讲中那样定义写偏斜：
写偏斜图案：
1.读东西
2.做出决定
3.写决定
在提交write（3）时，决策（2）的前提（1）不再为真
有一种悲观的方法，当我们基本上说“在给定的时间内只有一个主题可以使用共享资源时，其他人应该在主题完成之前等待”。
然后有一种乐观的方法，其阶段如Wikipedia所述：
I。开始：记录标记交易开始的时间戳。
二。修改：读取数据库值，并暂时写入更改。
三，验证：检查其他事务是否已修改此事务已使用（读取或写入）的数据。这包括在此事务开始时间之后完成的事务，以及可选的在验证时仍处于活动状态的事务。
IV。提交/回滚：如果没有冲突，则使所有更改生效。如果存在冲突，尽管可以采用其他解决方案，但通常可以通过中止交易来解决。
我的问题是，在进行验证（III）时，我们有什么保证不写新的“知识”，从而满足上面给出的写偏斜的定义？
基本上，阶段III的验证模块必须保留一些内部分类帐并以串行方式处理它们，以便在transaction1写入事件之前不会发生对transaction2的检查过程。
我们是否将写偏斜的整个问题降低了一层？因此，我们在低层次上有一个可序列化的悲观方法，以便能够在较高层次上有一个乐观方法？我有什么问题吗？
请您澄清一下。
答案 0 :(得分：1)
对于乐观锁定可以正常工作。验证”和“ IV。提交/回滚”必须是单个原子操作。因此，从这个意义上讲，是的，“我们只是将整个写偏斜问题降低了一层”。
但是，'II。修改”是数据库控制之外的用户操作，它可能需要很长时间才能完成，并且无法通过数据库实现进行优化。 'III。验证”和“ IV。 Commit / Rollback的OTOH是由数据库实现的操作，可以通过数据库实现将其优化为快速的操作。