@hnes logdb 的具体 roadmap 有吗? 这让人一头雾水啊

没有理解你这么做想干什么?

绑核也只是限定进程在哪些核上执行，而不是进程独占这个核

@zxCoder 针对 SELECT 当然是取决于你的语句来决定加什么锁.

Update 即修改 record 是自动加锁的, 你不需要做任何处理.

你是指没有显式的 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

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

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