必须使用mysqladmin shutdown等优雅关闭方式，而非systemctl stop或kill -9；需先检查活跃事务与连接，设innodb_fast_shutdown=0再关闭，确保事务落盘、binlog对齐、主从同步完成，并验证错误日志出现“shutdown complete”及pid文件删除。
直接执行 systemctl stop mysqld 或 kill -9 进程会导致未提交事务丢失、binlog 与数据文件不一致，甚至重启后卡在崩溃恢复阶段。必须确保所有事务落盘、复制位点对齐、服务优雅退出。
确认当前是否有活跃事务和长连接
强制关闭前不检查会跳过正在执行的 UPDATE 或 INSERT ... SELECT，造成部分写入、主从延迟突增甚至数据错乱。
- 登录 MySQL 执行：
SHOW PROCESSLIST;，重点关注State列为Updating、Copying to tmp table、Sending data的连接 - 查未完成事务：
SELECT * FROM information_schema.INNODB_TRX\G，看TRX_STATE是否为RUNNING，TRX_ROWS_MODIFIED是否 > 0 - 如发现长时间运行事务（> 30 秒），先评估影响，必要时用
KILL <code>trx_mysql_thread_id终止（仅限非关键业务时段）
执行安全关闭命令而非信号硬杀
MySQL 提供了内置的同步关闭机制，它会等待所有事务提交/回滚、刷脏页、写 checkpoint、关闭 binlog 日志句柄——这是避免数据损坏的核心步骤。
- 使用
mysqladmin shutdown -u root -p：该命令触发 MySQL 内部的shutdown流程，比系统级 kill 可靠得多 - 若配置了
innodb_fast_shutdown = 1（默认值），关闭时会跳过 full purge 和 change buffer merge，下次启动需额外恢复时间；生产环境建议提前设为0：SET GLOBAL innodb_fast_shutdown = 0;，再执行 shutdown - 不要依赖
service mysqld stop：某些旧版 init 脚本会直接kill -TERM，等效于粗暴中断，已知在 MySQL 5.7+ 中可能跳过innodb_buffer_pool_dump_now等保障动作
验证关闭是否真正完成且无残留风险
看似“服务停了”，但若 InnoDB 没完成 flush、或 relay log 未同步到 SQL thread 位置，重启后可能丢数据或主从断裂。
- 检查错误日志末尾是否有
Shutdown complete行（路径通常为/var/log/mysql/error.log或由log_error变量指定） - 确认
pid_file（如/var/run/mysqld/mysqld.pid）已被删除；若 pid 文件仍存在，说明 mysqld 进程未完全退出，不可强行删 pid 后启动 - 如果是主从架构，关闭前先在从库执行
STOP SLAVE;，并确认SHOW SLAVE STATUS\G中Seconds_Behind_Master: 0且Slave_SQL_Running_State: Slave has read all relay log
最容易被忽略的是 innodb_fast_shutdown 的默认行为——它让关闭变快，却把恢复压力转嫁到下一次启动。生产环境每次计划维护前，务必先设为 0 并等待几秒，再发 shutdown 命令。这不是多此一举，而是防止重启卡住 10 分钟以上的关键操作。
