myisam表崩溃需先通过grep -i "crashed|key file|error 145|error 1034"精准筛选.err日志确认真损坏，再执行check table验证，非ok即需修复；repair table失败时改用myisamchk -r -q或--safe-recover；修复后必须analyze table更新统计信息，且主从架构下切勿在主库误操作。
MyISAM 表崩溃后报错出现在 .err 日志里，说明损坏已落地到文件系统层，不能只看错误消息就开修——得先定位、再验证、最后选对命令和模式。
怎么看.err日志里是不是MyISAM真崩溃了
别一看到 Table is marked as crashed 就动手。MySQL 的 .err 日志里混着启动失败、权限拒绝、磁盘满等各类信息，必须过滤出真正跟 MyISAM 文件校验失败相关的行：
- 用
grep -i "crashed\|key file\|error 145\|error 1034" /var/lib/mysql/hostname.err精准抓取（路径以SHOW VARIABLES LIKE 'log_error';输出为准） - 如果日志里同时出现
myisamchk: error: Can't open file或record delete-link，基本可确认 .MYI/.MYD 文件头或索引块已损坏 - 注意区分：InnoDB 表崩溃通常表现为
InnoDB: Database page corruption或反复Assertion failure，这类日志绝不能用REPAIR TABLE
CHECK TABLE 返回 warning 但没报错，还要修吗
会。MyISAM 的 CHECK TABLE 有三档输出：OK、Warning、Error。只要不是 OK，就代表文件一致性校验失败，哪怕只是索引统计不准或某个空闲链表断裂，都可能在后续查询中触发 Incorrect key file。
-
CHECK TABLE table_name;返回Msg_text: warning→ 必须修复，优先用REPAIR TABLE table_name;（默认 QUICK 模式） - 若 QUICK 失败并提示
Failed repairing the table，说明数据页也有问题，立刻切到REPAIR TABLE table_name EXTENDED; - 别跳过
CHECK TABLE直接上REPAIR：有些“warning”其实是表被锁住导致的临时状态，误修反而引发死锁或中断
REPAIR TABLE 报 Can't repair table, need rebuild 怎么办
这个提示是 MySQL SQL 层给出的明确信号：.MYI 文件已无法解析，或者 .MYD 中存在不可跳过的坏块。此时必须退出 MySQL，改用底层工具 myisamchk。
- 先停服务：
systemctl stop mysql（确保 mysqld 完全退出，ps aux | grep mysql确认无残留进程） - 进数据目录执行：
myisamchk -r -q /var/lib/mysql/dbname/table_name.MYI（-r是修复，-q跳过部分校验加快速度） - 若仍失败，加
--safe-recover：myisamchk --safe-recover --force /var/lib/mysql/dbname/table_name.MYI，它会逐行扫描 .MYD 提取可读记录，重建最小可用索引 - 切忌在未备份时加
-o（覆盖重建）：它会丢掉所有索引定义，即使数据能读出来，主键/唯一约束也失效，应用层可能写入重复数据
修复完为什么 SELECT 还慢、COUNT(*) 卡住
MyISAM 修复不重算统计信息，REPAIR TABLE 或 myisamchk 后，表的行数、索引深度等元数据仍停留在损坏前的状态，优化器会基于错误基数生成低效执行计划。
- 立即执行：
ANALYZE TABLE table_name;，强制刷新 .MYI 中的统计信息 - 如果
ANALYZE TABLE报错或卡住，说明索引结构仍有隐性损坏，此时应考虑用mysqldump导出再重建表 - 特别注意：使用
USE_FRM模式修复的表，所有索引都是空壳，ANALYZE TABLE不起作用，必须手动ALTER TABLE ... ADD INDEX
最易被忽略的一点：MyISAM 修复全程不记 binlog，也不触发复制事件。如果你在主从架构下修复从库表，主库同名表其实仍是完好状态——别顺手在主库也跑一遍 REPAIR TABLE，那会把主库的正常索引干掉。
