该错误表明表引擎为InnoDB，而REPAIR TABLE仅支持MyISAM；应先查error.log确认是否真损坏，再根据引擎类型选择备份还原、innodb_force_recovery导出重建或转换引擎修复。
先看错误日志，别直接修表
“表打不开”不等于“文件损坏”，很多情况是权限、磁盘满或sql_mode限制导致的假性故障。第一步必须查error.log：执行SHOW VARIABLES LIKE '%log_error%'拿到路径，再用grep -i 'crashed\|corrupt\|errno' /var/lib/mysql/your-host.err过滤关键词。如果没出现具体表名+crashed或corrupted，就别碰REPAIR TABLE——优先检查：ls -l /var/lib/mysql/db_name/table_name.*是否缺失.frm或.ibd；df -h看磁盘是否100%；sudo chown -R mysql:mysql /var/lib/mysql确认归属。
CHECK TABLE 返回 error 才真要干预
CHECK TABLE是轻量诊断，但返回值含义得盯紧：
→ Msg_type: OK：表结构和主键索引一致，InnoDB 甚至不扫数据页，不能代表全量数据完好
→ Msg_type: error且Msg_text含record is crashed或key file is corrupted：MyISAM 确认损坏
→ Msg_type: warning且提示Found 1 delete link：只是碎片，OPTIMIZE TABLE就够了
注意：InnoDB表执行CHECK TABLE几乎不报物理损坏，若服务启动失败或日志里有Database page corruption，得跳过这步直接进innodb_force_recovery流程。
REPAIR TABLE 只对 MyISAM 有效，InnoDB 必须换思路
REPAIR TABLE在 InnoDB 上会立刻报错：ERROR 1031 (HY000): Table storage engine for 'xxx' doesn't support repair。MyISAM 用户可安全使用，但要注意：
• 必须有ALTER权限
• 表不能被其他会话写入，否则卡住
• 磁盘剩余空间得 ≥ .MYD文件大小的 2 倍（重建索引要临时空间）
• 三种模式选法：QUICK只修索引（快但不验数据）、EXTENDED逐行重建（慢但彻底）、USE_FRM仅当.MYI全毁且.frm完好时硬推（高风险丢数据）
InnoDB 用户唯一正解是：加innodb_force_recovery=1到[mysqld]段，重启后立刻mysqldump导出，再删库重建。数值从 1 试到 6，值≥4时INSERT/UPDATE/DELETE会被禁用，只留SELECT。
mysqlcheck 是运维首选，但参数极易配错
mysqlcheck支持在线批量操作，但-r和--repair是同一参数，-R是错的；常见误用：
• mysqlcheck -c db_name table_name -u root -p → 安全，先检查单表
• mysqlcheck -c -r db_name -u root -p → 检查并修复该库所有 MyISAM 表
• mysqlcheck -c --all-databases -u root -p → 全库扫描，但不会自动修复，必须加-r
它不处理 InnoDB 损坏，也不替代innodb_force_recovery。真正严重时，myisamchk离线修复更可控，但必须停 MySQL 或先FLUSH TABLES WITH READ LOCK，否则文件状态不一致。
最常被忽略的是：InnoDB 表损坏往往不是单个表的问题，而是ibdata1或共享表空间层面的 corruption，这时innodb_force_recovery可能无效，得靠备份还原——所以innodb_file_per_table=ON和定期mysqldump不是可选项，是底线配置。
