MySQL关机慢主因是innodb_fast_shutdown和innodb_buffer_pool_dump_at_shutdown参数配置不当：前者取值0会强制purge、merge、刷脏页导致数分钟延迟，取值1（默认）仅刷脏页适合日常，取值2最快但下次启动需crash recovery；后者默认开启会在关机时dump热页，大buffer pool下写盘拖慢关机。
MySQL 8.0 关机慢，大概率不是磁盘或CPU瓶颈，而是 innodb_fast_shutdown 和 innodb_buffer_pool_dump_at_shutdown 这两个参数在“认真工作”——关得越慢，说明它越想把数据留得越稳。
innodb_fast_shutdown 取值选错，关机直接卡住几分钟
这个参数控制 InnoDB 关机时要不要做“收尾清扫”。默认值 1 是折中选择，但如果你刚做完版本升级、或准备做主从切换，它就不够彻底；而如果你只是日常重启，设成 0 就会多花好几分钟等 purge 和 change buffer merge 完成。
-
innodb_fast_shutdown = 0：关机前强制刷脏页、合并插入缓冲、清理 undo 日志——安全但极慢，只应在升级/降级前手动执行一次 -
innodb_fast_shutdown = 1（默认）：跳过 purge 和 merge，只刷脏页——适合日常维护，关机通常在几秒到十几秒 -
innodb_fast_shutdown = 2：不刷脏页、不 merge、不 purge，只写日志就退出——像崩溃一样快，但下次启动要走 crash recovery，延迟明显
误设为 0 后关机耗时从 5 秒拉长到 6 分钟，查 SHOW ENGINE INNODB STATUS\G 的 LOG 和 BUFFER POOL AND MEMORY 部分，能看到 “purge done”、“change buffer merged” 等长时间等待日志。
innodb_buffer_pool_dump_at_shutdown=1 导致大 Buffer Pool 写盘拖慢关机
MySQL 5.7 起引入的热数据预加载机制，默认开启。关机时会把整个 innodb_buffer_pool_size 中最近活跃的页面（按 innodb_buffer_pool_dump_pct 比例）序列化到磁盘文件 ib_buffer_pool。如果 Buffer Pool 设了 12G，哪怕只 dump 25%，也要写几百 MB 到磁盘——尤其在机械盘或高负载 IO 场景下，关机就卡住。
- 确认是否启用：
SHOW VARIABLES LIKE 'innodb_buffer_pool_dump_at_shutdown'; - 临时禁用（无需重启）：
SET GLOBAL innodb_buffer_pool_dump_at_shutdown = 0; - 长期关闭：在配置文件中设为
0，避免每次重启都 dump - 注意：
innodb_buffer_pool_load_at_startup = 1会反向加剧启动慢，若已关 dump，建议同步关 load
其他容易被忽略的关机拖慢点
这几个参数不常被关注，但实际影响显著：
-
innodb_max_dirty_pages_pct：默认 90，意味着关机前可能要刷大量脏页。若业务写入频繁，可提前调低（如75），让刷页压力均摊到运行时，而非集中到关机瞬间 -
innodb_io_capacity和innodb_io_capacity_max：若 SSD 实际 IOPS 达 30K，但参数仍用默认 200，InnoDB 刷脏页会自我限速，关机时间翻倍 - 插件过多（尤其是审计类、监控类 UDF）：每个插件都要执行卸载逻辑，
SHOW PLUGINS;查一下有没有长期不用却没卸载的 - 未关闭的长 sleep 连接：
KILL掉TIME > 60且状态为SLEEP的连接，避免关机时等它们超时
真正耗时的关机，往往不是硬件不行，而是 MySQL 在“主动做太多事”。关机慢本身不是故障，是行为可预期的副作用——关键在于你是否清楚它在做什么、为什么做、以及你是否需要它这么做。
