MySQL启动失败时，先确认是否MyISAM表损坏导致：日志出现“Table is marked as crashed”或“Incorrect key file”，需停服后用myisamchk离线修复，不可用REPAIR TABLE（因mysqld无法运行），修复前必须备份三文件、确认引擎为MyISAM并确保磁盘空间充足。
MySQL启动失败时，先确认是不是MyISAM表卡住进程
断电后MySQL无法启动，常见表现是systemctl start mysql卡住、超时或直接退出，日志里反复出现Table 'mydb.user' is marked as crashed或Incorrect key file。这不是InnoDB崩溃那种“日志校验失败”，而是某个MyISAM表的.MYI索引文件损坏，导致mysqld在加载表结构阶段就阻塞。
别急着修表——先停服务：sudo systemctl stop mysql，再检查/var/lib/mysql/mydb/下对应表的user.MYI、user.MYD、user.FRM三个文件是否都存在且非零字节。如果.MYI为空或ls -l显示时间戳异常（比如早于断电前），基本就是它拖垮了整个启动流程。
用myisamchk修复前必须做三件事
MyISAM修复不可逆，myisamchk直接改物理文件，出错就真丢数据。动手前务必：
- 确认引擎确实是MyISAM：
SHOW CREATE TABLE mydb.user;输出里必须含ENGINE=MyISAM，不是InnoDB或其它 - 备份原始三件套：
cp /var/lib/mysql/mydb/user.{MYI,MYD,FRM} /backup/——哪怕只备份.MYI也比没有强 - 检查磁盘空间：
df -h /var/lib/mysql，剩余空间得 ≥ 该表.MYD大小的2倍，否则EXTENDED模式会中途失败并残留损坏碎片
myisamchk -r 和 REPAIR TABLE 的适用场景区别
REPAIR TABLE只能在MySQL正常运行时执行，而断电后mysqld根本起不来，这时候REPAIR TABLE连命令都发不出去。必须用离线工具myisamchk。
常用组合：
- 轻度索引损坏（仅
.MYI坏）：sudo myisamchk -r /var/lib/mysql/mydb/user.MYI——快，但失败率高 - 数据页也受损（
SELECT查出来字段错位、主键重复）：sudo myisamchk --safe-recover --force /var/lib/mysql/mydb/user.MYI——底层逐行提取可读数据，比SQL层更扛造 - 修复后别直接启动：先跑
myisamchk -c /var/lib/mysql/mydb/user.MYI，输出OK才算通过底层校验
修复完启动MySQL后必须验证数据有效性
修复命令返回OK不等于数据完好。MyISAM没事务，修复过程可能跳过损坏块，导致行偏移或字段值错行。
必须人工核验：
- 进MySQL执行：
CHECK TABLE mydb.user;，确认Msg_text列是OK，不是warning或error - 抽样查关键字段：
SELECT id, username, email FROM mydb.user LIMIT 5;，重点看主键是否连续、字符串字段有没有乱码或截断 - 对比业务逻辑：比如用户表里
status字段是否突然批量变成0，这种静默损坏CHECK TABLE发现不了
MyISAM修复本质是“抢救式读取”，不是回滚或重放。真正可靠的方案是定期mysqldump + binlog，而不是依赖myisamchk兜底。
