必须使用mysqladmin shutdown等优雅关闭方式，而非systemctl stop或kill -9；需先检查活跃事务与连接，设innodb_fast_shutdown=0再关闭，确保事务落盘、binlog对齐、主从同步完成，并验证错误日志出现“Shutdown complete”及pid文件删除。
必须先确保事务已落盘、主从位点对齐、InnoDB刷脏页完成，再触发优雅关闭；直接 kill -9 或 systemctl stop mysqld 极大概率导致数据页损坏或重启卡在崩溃恢复阶段。
检查活跃事务和长连接是否已清理
未结束的事务是关闭时最易引发页损坏的源头——InnoDB 在 shutdown 过程中需回滚或提交它们，若强行中断，可能留下不一致的页状态（如部分更新的索引页、未写入的 undo 日志）。
- 登录后执行
SHOW PROCESSLIST;，重点关注State为Updating、Sending data、Copying to tmp table的连接 - 查未提交事务：
SELECT * FROM information_schema.INNODB_TRX\G，确认TRX_STATE全为COMMITTED或ROLLING BACK已完成，且TRX_ROWS_MODIFIED = 0 - 若发现运行超 30 秒的事务，评估影响后用
KILL <code>trx_mysql_thread_id终止（仅限低峰期），避免mysqladmin shutdown卡住
设 innodb_fast_shutdown = 0 再执行关闭
该参数控制 InnoDB 关闭时是否跳过 full purge 和 change buffer merge。默认值 1 虽快，但会让下次启动多花数分钟做恢复，更关键的是：若此时恰好有脏页未刷、change buffer 未合并，重启时可能因页校验失败而报 Apparent corruption of an index page。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 执行
SET GLOBAL innodb_fast_shutdown = 0;（需 SUPER 权限） - 该操作会强制 InnoDB 在 shutdown 前完成所有 pending 的 purge 和 merge，确保页状态干净
- 注意：此命令本身不阻塞，但后续
mysqladmin shutdown会因此延长几秒到几分钟，属正常现象
用 mysqladmin shutdown 触发数据库层优雅退出
mysqladmin shutdown 是唯一能完整走通 InnoDB shutdown 流程的命令：它拒绝新连接、标记旧连接为 killed、等待事务收尾、刷 buffer pool、写 checkpoint、关闭 binlog 句柄、最后退出进程。整个过程由存储引擎自身协调，不依赖 systemd 或 init 脚本。
- 确保 root 用户有
SHUTDOWN权限（默认有，但若被显式回收会报Access denied） - 命令示例：
mysqladmin -u root -p shutdown；若 socket 路径非默认，加--socket=/var/run/mysqld/mysqld.sock - 若返回
Can't connect to local MySQL server，说明 mysqld 已无响应或连接耗尽，此时不能强关，应先查错误日志定位卡死原因 - 不要用
service mysqld stop：旧版脚本可能直接kill -TERM，跳过 InnoDB 的 flush 步骤
验证关闭完成且无残留风险
“服务没起来”不等于“已安全关闭”。InnoDB 若未完成刷盘，pid 文件仍存在、错误日志末尾无 Shutdown complete，都意味着进程未真正退出，强行启动会导致页损坏。
- 检查错误日志（路径由
log_error变量指定，常见于/var/log/mysql/error.log）末尾是否有Shutdown complete行 - 确认 pid 文件（如
/var/run/mysqld/mysqld.pid）已被删除；若仍在，说明 mysqld 进程未 clean exit，不可手动删 pid 后启动 - 主从架构下，从库须先执行
STOP SLAVE;并确认Seconds_Behind_Master: 0且Slave_SQL_Running_State: Slave has read all relay log - 最容易被忽略的是
innodb_doublewrite状态：若关闭前 doublewrite buffer 未刷完，重启时可能因页部分写（partial write）触发校验失败——这正是数据页损坏的典型诱因
