InnoDB重启预热时间更长，因其需按真实热度精准载入并校验热数据页；MyISAM无预热概念，仅依赖不可控的OS page cache。
MySQL重启后InnoDB预热时间比MyISAM更长，不是因为InnoDB“慢”，而是它在做MyISAM根本不会做的事：按真实访问热度，把热数据页从磁盘精准载入内存，并校验一致性。MyISAM不预热——它压根没这个概念。
innodb_buffer_pool_load_at_startup 加载的是 page ID 列表，不是数据本身
MySQL启动时加载ib_buffer_pool文件，只是读取一串页编号（page ID），然后逐个去 buffer pool 里查找、分配、校验这些页是否还有效。这个过程是 CPU 密集型的，不是 I/O 瓶颈。
- 若这些 page ID 对应的页已被 DROP/ALTER/TRUNCATE 覆盖，MySQL 会跳过或反复重试，拖慢进度
-
SHOW STATUS LIKE 'Innodb_buffer_pool_load_status';若长期卡在loading或返回Buffer pool(s) load failed，基本说明页已失效 - 临时解法：停库后删掉旧
ib_buffer_pool文件，让下次 shutdown 自动生成新 dump
buffer pool 太大 + dump 范围太宽 = 预热变成 CPU 空转
默认 innodb_buffer_pool_dump_pct = 25，意味着每次 shutdown 会 dump 最热 25% 的页。如果 buffer pool 是 16GB，dump 出来的文件可能达 10GB+，但实际活跃热数据可能只有 1–2GB。
- 用
ls -lh ib_buffer_pool查大小，再对比SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB' - 若 dump 文件 > 实际活跃数据 2 倍以上，说明 dump 范围过宽，应调小
innodb_buffer_pool_dump_pct至 5 或 10 - 确认是否真需要开启
innodb_buffer_pool_dump_at_shutdown = ON：如果实例每天重启多次，频繁 dump/load 反而得不偿失
预热线程和业务查询争抢资源，越急越卡
当 innodb_buffer_pool_load_at_startup = ON，MySQL 启动后立刻启动后台线程加载，此时若应用秒级发起大量查询，三件事会同时发生：
- 预热线程争抢磁盘 I/O（尤其随机读）
- 查询线程争抢 buffer pool mutex 和 free pages
- CPU 调度抖动加剧，表现为启动后前 30 秒
Free buffers接近 0、命中率hit rate持续低于 95%
这不是配置错，而是并发冲突。真正有效的缓解方式是应用侧加启动等待逻辑（比如轮询 SELECT 1 直到 Innodb_buffer_pool_read_requests 明显上升），而非硬扛。
最常被忽略的一点：InnoDB 的“预热”本质是重建访问局部性，而 MyISAM 的“快”来自彻底放弃局部性管理——它把数据文件全扔给 OS page cache，靠系统自发缓存，结果就是冷启动后第一次查某行可能慢得离谱，但没人知道为什么，也没人能控制。InnoDB 的长，是可控的长；MyISAM 的短，是不可信的短。
