必须执行innodb_fast_shutdown=0才能确保数据字典落盘，因其触发完整关闭流程：刷净脏页、写完Redo Log、清空Change Buffer；跳过此步将导致8.0启动时因字典页损坏或未持久化而报错。
升级前为什么必须让数据字典落盘？
MySQL 5.7 升级到 8.0 时，mysqld 启动会校验数据字典（mysql 系统库表）的物理结构和元数据一致性。如果升级前 ibdata1 或系统表空间里还有未刷盘的脏页，尤其是涉及 mysql.user、mysql.innodb_index_stats 等关键表的修改，启动时可能直接报错：Table 'mysql.user' doesn't exist 或 Incorrect information in file——不是表丢了，是字典页损坏或未持久化。
innodb_fast_shutdown=0 是强制落盘的关键
这是升级前唯一必须执行的落盘控制动作，不是可选项：
-
SET GLOBAL innodb_fast_shutdown = 0;—— 触发完整关闭流程：刷干净所有脏页、写完所有 Redo Log、清空 Change Buffer、确保ib_logfile*完全归档 - 执行后必须停服务：
systemctl stop mysql（或service mysqld stop），且确认无活跃事务（SELECT * FROM information_schema.INNODB_TRX返回空） - 跳过这步直接停服务，
innodb_fast_shutdown=1（默认）会跳过部分刷盘逻辑，导致 8.0 启动时拒绝加载旧日志，卡在“InnoDB: Starting crash recovery...”并失败
其他参数对字典落盘没有加速作用，反而可能干扰
别碰这些：
-
innodb_flush_log_at_trx_commit：只影响用户事务日志刷盘频率，对系统表空间和数据字典页的刷出无直接控制权 -
innodb_buffer_pool_size：调大可能延缓脏页积压，但不改变落盘时机；调小反而增加刷盘压力，拖慢整体关闭速度 -
innodb_log_file_size：影响 Redo Log 循环效率，但升级前已停写，不参与字典落盘加速 -
doublewrite：开启状态（默认）即可，关闭它会导致字典页写损坏风险上升，不是提速手段
真正起效的只有三件事
数据字典落盘不是靠“调参加速”，而是靠“按顺序做对动作”：
- 先执行
SET GLOBAL innodb_fast_shutdown = 0; - 再确认无活跃连接和未提交事务（
SHOW PROCESSLIST+INFORMATION_SCHEMA.INNODB_TRX） - 最后停服务，等待 mysqld 进程彻底退出（
ps aux | grep mysqld无残留）
做完这三步，ibdata1 和系统表空间里的字典页就已物理落盘。后续 mysql_upgrade 或 8.0 启动时读取的才是稳定一致的元数据状态。任何试图用“加大 buffer”“调小 log 刷频”来“加快字典落盘”的想法，都混淆了用户数据刷盘和系统字典持久化的机制边界。
