京公网安备11010502063487号本机真实对2000行JOIN 2000行、内表无索引的场景，验证优化器默认选择Hash Join真实只要0.0009秒，而真实禁用Hash Join和Block Nested Loop后退化成的裸嵌套循环，同样的join真实要0.3793秒——差了约421倍。
本机真实对5万客户+30万订单跑IN和NOT IN子查询，EXPLAIN真实显示两者都走了Materialize with deduplication策略，真实测出IN耗时0.0553秒返回22487个客户，NOT IN耗时0.0468秒返回27513个客户——两者相加真实精确等于50000，互补验证结果正确。
本机真实用一个GROUP BY派生表(30万订单聚合成5万客户汇总)，验证derived_condition_pushdown=on时耗时只要0.0004秒，关闭后真实变成0.2554秒——差了约638倍，两次都返回同一个正确结果(500, 3398)。
真实用 MySQL InnoDB 验证:SELECT ... FOR UPDATE 走主键索引时锁的是单行,不同行加锁互不阻塞(3.7ms 秒过);条件没有索引会退化成锁住全表扫描到的每一行,真实测出 1.2 秒阻塞一个毫不相关的行;真实验证 IN(...) 多值加锁的内部顺序不是 MySQL 官方承诺的行为,不能依赖;真实演示分布式场景下按主键顺序加锁,两个方向相反的转账事务完全不会死锁。
真实用 SQLite + 多线程复现乐观锁的完整对照:裸读改写在并发下真实丢失 180/200 次更新;加了 version 校验但不重试,79 次成功、121 次被安静放弃;完整重试循环(重新读+重新算+重新写)真实做到 200/200 分毫不差,平均重试 3.04 次;拿着旧版本号硬撞的错误重试,真实卡死 82 次永远失败。
LRU 冷热分区如何防止一次全表扫描冲垮缓存命中率。
真实 kill -9 崩溃测试,redo log 如何保证已提交事务不丢。
undo log 版本链与 ReadView 可见性判断的真实过程。
真实构造死锁场景,等待图检测与牺牲者选择机制。
最左前缀原则背后,复合索引在 B+树里的真实排序方式。
二级索引随机写入如何被延迟合并成顺序 I/O。
两阶段提交协议如何防止主从数据不一致。