@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 来做.

@TimePPT CV 方向的, 用云费钱，感觉不如自己装一个 GPU 的主机跑跑

www.leviathan.vip

别想了 就是我

开启 Intel 的 PAE （物理地址扩展）模式就可以

1. 整一个 lock 文件
2. 文件起始位置用一个 Byte 标记状态..

好多办法监控 看你想怎么搞了

开源吗 之前想基于 OCR 搞一个

针对 RR 级别 非常容易出现死锁. 不过 InnoDB 的死锁检测会回滚其中的一个事务, 我给你举个例子, 依然以你的数据表:

session 1：
create table xxx...;

INSERT into test (id,age) values (1,1);

INSERT into test (id,age) values (2,2);

begin;

update test set age=1 where id=1;


这时候切换到 session 2, 记住 session 1 不要 commit

session 2:
update test set age=2 where id=2;

session 1:
update test set age=2 where id=2;

session 2:
update test set age=1 where id=1;

这时候你就在 session 2 可以看到你想看到的死锁提示.

@huntcool001

更新 table 是有 table lock 的, 只是表锁后面会降级为意向锁.

你纠结的问题是先锁 二级索引 还是 主键索引.
对于查询来说你的逻辑是对的，但是修改还是先改聚簇索引，再改二级索引 ( InnoDB 里所有非聚簇索引均为二级索引).

RRjibie. InnoDB 的 record 锁只有在 trx commi t 之后才释放.

当一个二级索引列被更新的时候，旧的二级索引记录被标记为删除，同时插入一个新的二级索引记录

1. open 的时候加参数 binary
2. 写对齐没有意义

内容需要持久化吗

NULL 就是一个标志位

淘宝 同桌英语
一节课 50 菲律宾外教 发音都还可以 入门练个口语足够了

"远超理论最大内存" 这个理论最大内存你是哪里得出的?

buffer pool 配置了多大, MySQL 的 buffer pool 是 mmap 映射