@gBurnX block 了 ，不懂数据库就不要出来误导别人，看下帖子有多少人说你不对了.

@hehe12980 DDL 的升降锁过程手动启 session 是很难能卡在临界点的, 8.0 的 DDL 是 atomic DDL, prepare 和 commit 阶段都是阻塞读写的，包括你说的快照读.

@hehe12980 需要我给你翻代码吗? MySQL 的 DDL 有一个升降锁的过程，加 X 锁的时候全都不能读写.

@gBurnX 不懂就不要瞎说了 误导别人

@leavan select 默认不会加锁, 是快照读. MVCC 可以保证. @nolo 3 楼说的 DDL 阻塞 select 是因为 DDL 会对表 加 X 锁，禁止读写.

@zxCoder MySQL 不存在脏写，因为采用 2PL 加锁机制, 所以你说的情况不会发生。

@gBurnX 我前面提到了 每个事务来判断 record 的 0 或 1 即可。

你可能要问如何保证读取这个标志位的原子性呢，这需要 latch 互斥，这是两个问题，并不涉及事务锁的问题。

@gBurnX 逻辑锁的意思通俗解释是 0 代表持锁，1 代表不持锁，事务是否持有锁只需要判断状态位为 0 或者 1， 并不需要你所说的操作系统的锁来实现.

@gBurnX 操作系统的锁在数据库称为 latch，行锁，表锁在数据库都是逻辑锁.

你才大一，好好学习。

@gBurnX

”如果你完整地从底层开始，逐步学习了这些知识，按照层次划分，数据库的锁就是对 OS 提供的进行包装而已。

但如果你没有系统地构建知识树，你可能会说，数据库的锁本质是由更下层的模块提供，比如指令，CPU 甚至电路等等。你这种说法当然也没错”

通过你的说法 我甚至可以判断你根本不理解数据库里的锁是什么.

@gBurnX 数据库的锁和操作系统的锁并不是一种锁，更不是进一步包装

这块涉及的内容比较多了 想深入了解只能看源码了 有问题上社区 https://fastdb.cc/ 问我咯.

@magichacker 不会前端 不会调整。。。

@zxCoder 当然 欢迎在数据库社区提问关于数据库内核的问题 https://fastdb.cc/

@zxCoder 我理解你的意思了 我看了一下源码 大于等于都是不可见的 你看的书描述不准确.

@zxCoder 我不确定我是否正确的理解了你的问题.

你说的那种情况下: 无法保证后启动的事务先 commit.

t1 t2 两个事务, t1 先启动 ，但早于 t2 commit.

max_trx_id 是 trx_sys 里的 这是全局的
creator_trx_id 是 read view 里的

@longfxxx 用的是 Discourse 框架，选了个主题和两个插件，没有特别复杂.

@zhangysh1995 @karloku 现在正常了 因为论坛加了 HTTPS 导致之前的链接失效了