MySQL 生产检查清单

适用 MySQL 8.0（InnoDB）。每条都可勾选，括号内是默认值或判断依据；版本差异以官方文档为准。这份清单只列「不做会出事」的动作，机制解释见各篇正文。

上线前

[ ] 双 1 刷盘已确认：innodb_flush_log_at_trx_commit=1、sync_binlog=1（MySQL 8.0 默认），commit 返回前完成 Redo 与 Binlog 两次 fsync；从库和备份链路能接上 Binlog。
[ ] Binlog 可用且留够：binlog_format=ROW（8.0 默认）；保留期覆盖「备份周期 + Canal 最长中断时间」；8.0 用 binlog_expire_logs_seconds 设置，expire_logs_days 已废弃（以官方文档为准）。
[ ] 主键容量够用：核心表主键用 BIGINT，不用 INT（上限约 21 亿且删除后不复用）；自增使用率 >70% 告警。
[ ] 写路径都有索引：所有 UPDATE/DELETE 的 WHERE 必须命中索引，否则扫描到的行全部加锁、退化为表锁；开启 sql_safe_updates=1，大表清理用 pt-archiver 分批。
[ ] 大表 DDL 不阻塞业务：用 pt-osc/gh-ost；DDL 前确认没有长事务，并设置 lock_wait_timeout（默认以官方文档为准），避免 MDL 写锁排队拖死全库。
[ ] 备份真的能恢复：全量备份 + Binlog 可恢复到指定时间点，且本季度做过一次真实恢复演练；只确认备份文件存在不算。
[ ] Canal 前置条件齐备：binlog_format=ROW、全局唯一 server_id、具备 REPLICATION SLAVE 权限的账号；Client 持久化消费位点；业务大事务拆小，避免解析卡住。

[ ] 长事务：information_schema.innodb_trx 中 trx_state='RUNNING' 持续超过 60 秒告警；长事务同时阻止 Undo 回收并放大 MDL 风险。
[ ] 慢查询：slow_query_log=ON、long_query_time=1（默认 10 秒，生产建议 1 秒）；每周用 mysqldumpslow -s t -t 10 复盘总耗时 Top 10。
[ ] 主从延迟：SHOW SLAVE STATUS 看 Seconds_Behind_Master 与 Relay_Log_File；延迟持续升高先查大事务和无主键表。
[ ] 容量与统计信息：数据目录、Binlog 目录、Undo 表空间使用率 70% 预警；大批量变更后立即 ANALYZE TABLE，避免统计信息过期导致选错索引。

[ ] CPU 正常但磁盘暴涨 → SELECT * FROM information_schema.innodb_trx WHERE trx_state='RUNNING' → 有小时级未提交事务，Undo 无法回收 → kill 会话，并给应用加事务超时。
[ ] ALTER TABLE 卡住、后续查询全排队 → performance_schema.metadata_locks → 长事务持有 MDL 读锁 → kill 长事务，改用 gh-ost 重做。
[ ] 查询从毫秒变秒、EXPLAIN 用了错索引 → ANALYZE TABLE 更新统计信息 → 仍不对再 FORCE INDEX，并把该 SQL 的 EXPLAIN 纳入发布检查。
[ ] 报死锁、事务被回滚 → SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK → 按统一顺序加锁、缩短事务、确认 WHERE 走索引；innodb_deadlock_detect 默认开启。