repair table 报错“the storage engine for the table doesn't support repair”是因为该命令仅支持 myisam 引擎，而 innodb 表不兼容；应先用 show table status 确认引擎，若为 innodb 则需通过重启触发崩溃恢复或启用 innodb_force_recovery 导出重建，切勿强行修复。
REPAIR TABLE 报错 “The storage engine for the table doesn't support repair” 怎么办
这个错误不是复制层问题，而是你在从库（或主库）上手动执行 REPAIR TABLE 时触发的——InnoDB 表根本不能用这条命令修复。别慌，这不是同步中断，只是你误用了不兼容的操作。
-
REPAIR TABLE只对MyISAM有效；InnoDB依赖事务日志和崩溃恢复机制，不提供“在线修复”接口 - 先确认引擎：运行
SHOW TABLE STATUS LIKE 'tblname'，看Engine字段；如果是InnoDB，立刻停用REPAIR TABLE - 若表真损坏（如崩溃后启动失败、查询报
Table is marked as crashed），应优先检查错误日志里是否有InnoDB: Database page corruption类提示
InnoDB 表出问题，该用什么替代方案
不要硬修，要靠机制恢复。InnoDB 出问题，核心思路是“让崩溃恢复生效”或“重建”。
- 重启 MySQL 实例：多数轻微页损坏会在重启时被
InnoDB自动检测并尝试恢复（前提是innodb_force_recovery未设为非零值） - 若重启失败且日志明确提示页损坏，可临时启用
innodb_force_recovery=1（仅读），导出数据后重建表：mysqldump -u root -p db tbl > tbl.sql，再删表重导 - 绝对避免在生产从库上直接
DROP TABLE后重建——这会破坏复制位置；必须先STOP SLAVE，确认Relay_Master_Log_File和Exec_Master_Log_Pos，再操作
为什么从库上突然执行 REPAIR TABLE？警惕人为误操作
主从同步本身不会调用 REPAIR TABLE。如果你在从库看到这个报错，大概率是运维或脚本误触发了修复逻辑——尤其当监控脚本自动扫描“状态异常表”并统一执行修复时。
- 检查是否启用了
read_only=OFF：从库默认应为ON，否则应用或 DBA 可能直连写入或执行 DDL/repair - 排查自动化任务：搜索 crontab 或运维平台里是否含
REPAIR TABLE关键词的脚本，特别是针对information_schema.TABLES中Comment含corrupt的判断逻辑 - 修复脚本应加引擎白名单过滤：执行前先查
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='tbl'，只对MyISAM表调用REPAIR
主从结构不一致导致的“伪损坏”误判
有时候 SHOW TABLE STATUS 显示 Rows 为 NULL 或 Auto_increment 异常，会被监控脚本误判为“损坏”，进而触发 REPAIR TABLE ——其实只是主从表结构不同步造成的元数据偏差。
- 典型场景：主库执行了
ALTER TABLE t ADD COLUMN c INT，但从库漏同步（比如跳过了该 DDL），导致从库表少一列；此时SHOW TABLE STATUS可能返回异常值，但表本身可读写 - 验证方式：对比主从库的
SHOW CREATE TABLE t输出，逐字段比对列名、类型、索引 - 修复优先级：先用
pt-online-schema-change补全结构，而不是跑修复命令——REPAIR TABLE对结构缺失毫无作用
