备份前必须先CHECK TABLE验证表状态，再结合DATA_FREE和错误日志判断是否需OPTIMIZE或REPAIR；OPTIMIZE适用于InnoDB碎片整理，REPAIR仅限MyISAM抢救修复，二者均不可自动化嵌入备份脚本。
MySQL OPTIMIZE TABLE 和 REPAIR TABLE 到底该用哪个
备份前不检查表状态，等于把损坏或碎片化的数据原样存档——恢复时才发现问题，已经晚了。不是所有表都适合直接 optimize table，尤其在 innodb 下它本质是重建表，会锁表、耗 i/o；而 repair table 仅对 myisam 有效，innodb 遇到损坏得靠 innodb_force_recovery 或从备份恢复。
-
OPTIMIZE TABLE主要解决行碎片和空间浪费，适合长期增删改后Data_free明显偏高的表（查SHOW TABLE STATUS） -
REPAIR TABLE是抢救性操作，只应在CHECK TABLE明确报出error或warning后使用，且必须停写 - InnoDB 表若
CHECK TABLE返回OK，通常无需REPAIR；OPTIMIZE可用ALTER TABLE ... ENGINE=InnoDB替代，更可控
备份前必须跑的三步检查：CHECK TABLE + 状态验证 + 错误日志扫视
跳过检查直接备份，相当于闭眼装弹——不知道子弹有没有受潮。重点不是“有没有错”，而是“错会不会影响备份一致性”。
- 对每个待备份表执行
CHECK TABLE table_name EXTENDED；EXTENDED能触发索引校验，但会加读锁，建议在低峰期跑 - 检查
information_schema.TABLES中DATA_FREE是否远大于平均行大小 × 行数（比如超 20%），这种表优化收益明显 - 翻一遍 MySQL 错误日志，搜
"corrupt"、"failed"、"InnoDB: Database page corruption"—— 这些信号比CHECK TABLE更早暴露底层问题
Percona Toolkit 的 pt-online-schema-change 能不能替代 OPTIMIZE 做在线整理
不能。它设计目标是改表结构，不是整理碎片。强行用它“重建”来优化，反而引入额外风险：主从延迟、触发器冲突、临时表残留。
-
pt-online-schema-change --alter "ENGINE=InnoDB"看似等效，但会多一层复制逻辑，失败回滚复杂，且无法跳过唯一键重复校验等开销 - 真正需要在线优化的场景（如大表不能锁），应优先考虑 MySQL 5.7+ 的
ALGORITHM=INPLACE（如ALTER TABLE ... FORCE），它复用原表空间，速度更快、锁更轻 - 如果必须用 pt 工具，只用于结构变更，优化动作仍应放在备份窗口内，用原生命令集中处理
备份脚本里嵌入修复逻辑的致命陷阱
在 mysqldump 前自动执行 REPAIR TABLE 或 OPTIMIZE TABLE 是危险操作。一旦某张表修复失败或优化卡住，整个备份流程就中断，你还得手动清理中间状态。
- 修复类操作必须人工确认结果：
REPAIR TABLE返回status: OK才算成功，status: Error或status: warning都需介入 - 自动化脚本里最多只做
CHECK TABLE并记录结果，发现异常立刻退出并报警，而不是尝试自动修 - 优化类操作建议单独跑批处理，和备份解耦；备份脚本只依赖
mysqldump --single-transaction（InnoDB）或--lock-tables（MyISAM）保证一致性即可
最常被忽略的是：CHECK TABLE 在只读实例上可能返回缓存结果，实际主库已损坏。所以检查必须在备份源节点上执行，不能图省事在从库做。
