哈哈。我为什么有点想笑。

@xtx 我手上的 mbp 也不敢升到 big sur 。

1 、因为数据库本身是一个很复杂的东西。要考虑很多层面上的东西，比如事务隔离级别，MVCC，锁等等相关的情况。暴露外面的接口看上去都是 CRUD 的简单接口，但事实上内部实现极其复杂，要考虑很多东西。
2 、「按书上的做法，页面的 UserRecords 里的记录删除后只是会先打一个标记，那么为什么不这样做，比如这个页面的记录在我们代码中体现的就是一个 LinkList，我们可以直接删掉要删掉的记录，再序列化写回磁盘里。」这里为什么不能直接删除了？打个比方，在 RR 隔离级别下，事务 A select id=1,事务 B 然后 delete=1，commit;然后事务 A 在 select id=1，你会发现事务 B 的删除根本对事务 A 没什么影响。所以这里要考虑数据在不同的隔离级别的可见性。

为什么我觉得 SONY 的系统用的还行。

搬来想买两件的，发现运费太贵了。。。

@lewis89 next-key 是 gap lock 和 record lock 的结合体。

@wps353 应该是 insert into user values(2)

我是这么认为的，不知道对不对。
MySQL 的幻读和 SQL 标准的幻读有所差异。
MySQL 中幻读是针对当前读.
举个例子：
在 RC 级别下，user 表 id >=1 and id <=10 的数据现在只有 id=1 一条数据。这时候事务 A 执行 SQL(delete from user where id >=1 and id <=10),未 commit ； 如果此时事务 B 执行 SQL （ insert into user values(5)) 。这时候我们再提交事务 A，你会发现 user 里面居然还有一条 id=2 的记录，这和我们事务 A 执行的结果预期不符。
那么这个 id=2 的记录就属于幻读。
所以 MySQL 在 RR 级别下用 next-key 来保证例子中的事务 B 是插不进去的。

离职证明，是用人单位与劳动者解除劳动关系的书面证明，是用人单位与劳动者解除劳动关系后必须出具的一份书面材料。（百度百科）

参考一下 Orchestrator，把你的监控和高可用都解决了。

@gzd1214
d3BzMzUy(base64)，谢谢

@gzd1214 没咖喱节点