你是指没有显式的 begin 吗?

update 语句依然需要排它锁.

事务中写不写 FOR UPDATE 和 LOCK IN SHARE MODE 取决于你的需求啊.

1. select 是否加锁要看是什么类型的 select 语句:
* 快照读不需要加锁, MVCC 的 undo log 能保证读到正确的数据.
* shard mode 加 s 锁.
* for update 加 x 锁.

2. InnoDB 使用 Next-key Lock 解决了 RR 部分场景下的幻读，也不是完全的避免幻读.

@silenceeeee 你理解的没有错 next-key lock 是 record lock 加 record 前面的 GAP lock. 但为什么你这个场景后面的 GAP 也锁住了呢?

因为表中的 `a` 字段不是二级唯一索引, 所以你执行 session 1 的时候会有 3 个锁:

1. 索引 `a` 上的 '7' 的 next-key lock.
2. 主键索引上 '3' 的 record lock.
3. 索引 `a` 上的 '10' 的 GAP lock. 即 [7, 10)

InnoDB 的加锁逻辑是遍历到下一个 record 然后添加 GAP LOCK

你没有理解操作系统中什么是虚拟内存，什么是物理内存

性能当然是不错的，迁移之前自己先压测试试.

@xsm1890 这是 B+ tree 的组织方式，和 .ibd 没有关系.

@xsm1890 你这是哪里看的 InnoDB 的 B+ tree 插入一个 record 只占一个 Page, 没有什么单独的索引, 索引即数据.

@zxCoder 假如是考虑写, mmap 和 buffer pool 的作用一样，一个是系统级的 Page Cache, 一个是应用级的 Page Cache, 操作系统和 buffer pool 一样可以设置刷脏阈值, 本质上没有特别大的区别。

读场景例如 InnoDB 采用的不是朴素的 LRU，里面将 LRU 区分为 old + young 区域, 目的是为了不让一个随机读的 Page 打乱 LRU, 读这块数据库可以做的很多.

一般使用 Buffer Pool, 都是尽可能多的占用内存, 数据库可以自己考虑刷脏的时机等等..

假如只考虑写 mmap 和 buffer pool 的作用是一样的，但数据库还有读.

数据库实现者认为数据库来控制内存比操作系统控制效率更好, 所以很少看到数据库实现是靠 mmap 来做.