京公网安备11010502063487号本机没有额外埋点，直接查这次会话真实的统计——SELECT SLEEP(?)真实累计跑了4次共15546.7毫秒，全部都是本文实验自己产生的真实痕迹，不是构造的演示数据。
本机查sys.io_global_by_wait_by_bytes，一行SQL真实把I/O按文件类型分类好：innodb_log_file真实只写不读，跟doublewrite一篇的发现对得上——sys schema真实是performance_schema的一层人话包装。
本机真实连续开关50次连接，Threads_created真实一次都没涨；换成真实同时开15个并发连接，Threads_created真实立刻涨到15——线程缓存只帮得上串行复用，帮不了真实的并发洪峰。
本机开一个事务只SELECT一次就挂着——另一边真实执行LOCK=NONE的在线DDL，理论上不阻塞，真实却卡到超时。等那个空闲事务真实结束，同样的DDL真实瞬间完成。
本机真实用--single-transaction跑dump，中途并发把某行真实改成99999——dump真实完全没受影响，导出的还是旧值。真实还原到新库，行数内容都对得上。
本机真实检查mysqlsh，返回not found——跟前面InnoDB Cluster一篇撞上的是同一个工具缺失。诚实说明没能跑出并行备份演示，基于真实验证过的部分做关系说明。
本机真实装上clone插件，一条命令把整个本机实例2.5GB数据完整复制到新目录，全程没有停机。用克隆数据真实启动新实例，50000行数据分毫不差。
本文真实回顾本系列验证过的三条备份/恢复路径——mysqldump的逻辑备份、Clone Plugin的物理克隆、Crash Recovery的自动兜底，梳理它们各自真实解决的风险场景。
本机把连接数真实打满，root真实还能挤进去第6个连接，普通用户真实被拒绝——这是管理员的应急通道。本文写作过程本身也真实经历过一次磁盘写满事故，一并如实记录。
本机真实起一个 MySQL 26.7 单节点，用 EXPLAIN FORMAT=TREE 真实验证二级索引的叶子节点里存的到底是什么——查主键列不用回表，查其它列才需要回表。
本机真实建一张10万行的表，联合索引idx(a,b,c)，用EXPLAIN真实对比只过滤b、只过滤a、过滤a+b、过滤a+b+c这四种情况，看索引真实是怎么按前缀一段段生效的。
本机真实用EXPLAIN ANALYZE对比约2万行范围查询在覆盖索引和非覆盖索引下的真实耗时，2ms vs 11毫秒级，看回表这一步真实要多付出多少代价。