直接执行REPAIR TABLE是最常用有效方式，但须先确认引擎为MyISAM、无并发写入；若索引文件彻底损坏，应使用USE_FRM模式重建索引。
MyISAM表崩溃后出现 Table is marked as crashed and should be repaired 怎么办
直接执行 REPAIR TABLE 是最常用且有效的应对方式，但必须在明确表引擎为 MyISAM、且没有其他进程正在写入该表的前提下操作。MyISAM 不支持事务和行级锁，崩溃后索引文件（.MYI）或数据文件（.MYD）极易不一致，错误信息就是内核在打开表时校验失败的直接反馈。
实操建议：
- 先用
SHOW TABLE STATUS LIKE 'table_name';确认Engine字段确实是MyISAM，避免误对 InnoDB 表执行修复（InnoDB 会忽略该命令） - 确保没有应用正在写这个表——否则
REPAIR TABLE可能中途失败，甚至让损坏加剧 - 若表较大，加
USE_FRM选项：REPAIR TABLE table_name USE_FRM;，它会跳过读取.MYI头部，仅依赖.frm结构重建索引，适合索引文件彻底损坏的情况 - 如果提示
Incorrect key file for table，说明.MYI已不可信，必须用USE_FRM
mysqld 启动时卡在 Checking table 阶段怎么跳过
MySQL 启动时默认会对所有 MyISAM 表执行 myisamchk --check，一旦遇到损坏表，就会阻塞启动流程。这不是“检测”，而是同步阻塞式校验，尤其在大量小表或磁盘响应慢的环境中特别明显。
实操建议：
- 临时跳过：启动时加参数
--skip-concurrent-insert --skip-myisam-recover-options（MySQL 5.7+ 推荐用--skip-myisam-recover） - 永久禁用：在
my.cnf的[mysqld]段下添加myisam-recover-options=OFF（注意不是myisam_recover，旧版本拼写不同） - 更稳妥的做法是保留自动检查，但指定只检查关键库：用
myisam-recover-options=FORCE,BACKUP，这样即使出错也会尝试修复并备份坏块 - 切勿在生产环境长期关闭自动恢复——它虽慢，却是防止静默数据腐烂的最后一道防线
myisamchk 命令修复失败报 Can't change size of file 怎么处理
这个错误通常意味着磁盘空间不足，或文件系统权限/挂载选项限制了文件截断（如只读挂载、noexec、或 ext4 的 barrier=1 在异常掉电后引发元数据不一致）。myisamchk 在修复过程中需要重写 .MYD 和 .MYI，中间会生成临时文件并调整大小。
实操建议：
- 先运行
df -h和df -i，确认目标分区不仅空间够，inode 也要充足（尤其小文件多的场景） - 检查 MySQL 数据目录挂载参数：
mount | grep mysql，避免出现ro或noatime,errors=remount-ro导致实际只读 - 手动执行前，cd 到数据目录，用
myisamchk -r -v table_name.MYI（加-v看详细步骤），比REPAIR TABLE更早暴露底层 I/O 问题 - 若仍失败，可尝试先
cp table_name.MYD table_name.MYD.bak，再用myisamchk -o（安全模式，不修改原文件）验证是否能读出记录数，判断损坏程度
修复后查询结果乱码或缺失部分数据怎么办
MyISAM 的修复本质是重建索引+按记录头扫描数据，一旦 .MYD 中某条记录的长度字段损坏，后续所有记录都可能被错位解析，表现为字段值串行、NULL 值异常增多、甚至整行消失。这不是修复失败，而是原始数据已物理损坏。
实操建议：
- 立刻停止对该表的所有写入，用
SELECT COUNT(*)和SELECT COUNT(*) FROM table_name WHERE pk IS NOT NULL对比，看主键是否大面积丢失 - 若有备份，优先从最近一次
mysqldump --tab或mysqlhotcopy恢复（这两者对 MyISAM 是原子拷贝） - 若无备份，尝试用
myisamchk --safe-recover（比-r更保守），它会跳过无法解析的记录，但保留尽可能多的完整行 - 永远不要依赖
REPAIR TABLE EXTENDED来“抢救”严重损坏的表——它会强行填充默认值，掩盖真实损坏范围
MyISAM 的脆弱性不在修复命令本身，而在于它把数据一致性完全交给操作系统和管理员的手动干预。只要还有未刷盘的 key_buffer 缓存、或 delay_key_write 开启，一次意外断电就足以让修复变成猜谜。真正要做的，不是练熟 myisamchk 参数，而是尽快迁移到 InnoDB 并确认 innodb_flush_log_at_trx_commit=1 和 sync_binlog=1 已生效。
