这把你牛逼的

就是你说的 CPU 中断处理

@JasonLaw 那就直接看代码 看别人写的文档都是二手资料

这条 log 上面还有一部分 Log 贴上来才知道哪里 crash 了啊

@JasonLaw 第二个问题 你要纠结这个细节 不妨直接看源码 我们讨论的是可重复的隔离级别 我说的是事务创建时就创建 read view:

mysql-server/blob/8.0/storage/innobase/handler/ha_innodb.cc#L5170

5170 行是创建可重复读隔离级别的事务

5190 行启动

5199 行分配 read view

接上条 漏了一点

t2 修改 id=5 的 record 为 v2 后就提交 commit.

你这个理解可能不太对

可重复读是事务隔离级别

你在文章里写的:

因为 session 1 执行 select * from t where id = 5 for share 之后，会拥有表级别的共享意向锁和 id 为 5 的那个索引记录的共享锁，所以 session 2 虽然获取到了表级别的独占意向锁，但是它无法获取到 id 为 5 的那个索引记录的独占锁。任何事务都不能够修改或删除 id 为 5 那行，因此保证了可重复读。

最后一句" 任何事务都不能够修改或删除 id 为 5 那行，因此保证了可重复读。" 这句表述的不对，一个事务可以有多条语句，s1 创建事务 t1 用 record lock 锁住了这条 record, 但它执行 t1 后面的语句时，这把 record lock 已经被放开了. 其他事务的是可以修改的 id 为 5 的 record.

MySQL 如何实现可重复读?
利用 MVCC

在 MySQL 中 MVCC 是 undo log + read view，依然以你的例子举例:
s1 创建事务 t1 时会创建 read view 即 r1,
s2 创建事务 t2 时会创建 read view 即 r2.

t1 第一次读 id=5 的 record 为 v1,
t2 修改 id=5 的 record 为 v2,
t1 再次读的时候会利用 read view 即 r1，判断 v2 是否可读，它会发现 v2 的 trx_no 大于 r1 的 trx_no, t1 就利用 undo log 回溯上一个版本即 v1. 这是可重复读.

@aheadlead 我当然知道 mmap 返回的是用户地址空间

读写文件: 用户调用 mmap --> 申请 VMa --> VMa->file 指向对应的 file --> address_space --> page cache
真正读写的时候触发缺页中断，kernel 读 page 至 page cache, 用户通过 VMa 可以直接访问 page, 难道用户进程还能直接读文件?

@vk42 你前面提了 Page Cache, 所以我问你 Page Cache 在哪里?

不懂就看源码 更别给学生出题 误人子弟

@vk42 听不懂我说什么就算了

@vk42 去看看源码 mmap_region() --> call_mmap(file, vma)

vma 指向的是哪里 你说 page cache, 那 page cache 在哪里? 块设备接口读的内容存在哪里的?

@vk42 vma 映射的不是内核地址空间? 访问 vma 不是访问内核地址空间?

@vk42 自己看源码吧 懒得解释了

接上一条 拷贝的原因是因为进程申请的 buf 都是用户空间的虚拟地址，就如你用 mmap 也是可以直接访问内核态的地址空间，这就省去了一次拷贝

是真的拷贝一次啊

函数就是 copy_to_user()

unsigned long copy_to_user ( void __user * to,
const void * from,
unsigned long n);

@UnAmico undo log 保证的事务原子性，指的不是“事务过程中如果数据库崩溃, 还是需要通过 redo log 实现的回滚”，这里指的是事务内的语句要么全部执行成功，要么全部失败. 假如事务 rollback, 需要通过 Undo log 恢复到之前版本的数据. 事务的一致性在 MySQL 中使用的是 MVCC.

?

自己作曲的吗?

分母