mysql突发断电后无法启动，大概率是mysql.user等myisam系统表的.myi索引文件损坏所致；须先用show create table确认engine=myisam，再停服务、备份三件套、用myisamchk -r或--safe-recover离线修复，并验证无误后重启。
MySQL突发断电后无法启动，大概率是某个MyISAM表的.MYI索引文件损坏卡住了加载流程——不是所有表都要修，但mysql.user这类系统表一旦损坏，mysqld根本连初始化权限模块都过不去。
先确认是不是MyISAM表真坏了，别修错引擎
断电后MySQL起不来，日志里反复出现Table './mysql/user' is marked as crashed或Incorrect key file for table，基本就是MyISAM在作祟。但得先验证：
-
SHOW CREATE TABLE mysql.user;输出里必须含ENGINE=MyISAM——InnoDB表执行REPAIR TABLE会直接报ERROR 1031 - 查错误日志位置：
SELECT @@log_error;，然后grep -i crashed /var/lib/mysql/*.err - 别依赖
CHECK TABLE：系统表严重损坏时，这条命令本身可能卡死或无响应
mysqld起不来时，只能用myisamchk离线修复
这时候REPAIR TABLE发不出去，因为MySQL进程压根没起来。必须切到shell，停服务后直操作文件：
- 先停服：
sudo systemctl stop mysql（确保进程完全退出） - 定位文件：
/var/lib/mysql/mysql/user.MYI（路径以你datadir为准） - 快速校验：
myisamchk -s /var/lib/mysql/mysql/user.MYI，看是否报is not closed或record delete-link chain broken - 轻度损坏（仅索引断裂）：
myisamchk -r /var/lib/mysql/mysql/user.MYI - 数据页也乱了（查出来字段错位、主键重复）：
myisamchk --safe-recover --force /var/lib/mysql/mysql/user.MYI
修复前必须做的三件事，漏一个就可能丢数据
MyISAM修复不支持回滚，myisamchk直接改物理文件，出错即不可逆：
- 备份原始三件套：
cp /var/lib/mysql/mysql/user.{MYD,MYI,FRM} /backup/——哪怕只备份.MYI也比没有强 - 检查磁盘空间：
df -h /var/lib/mysql，剩余空间必须 ≥ 对应.MYD大小的2倍，否则--safe-recover会中途失败并残留损坏碎片 - 确认引擎无误：
SHOW CREATE TABLE mysql.user;再扫一眼，避免把InnoDB表当成MyISAM去修
修完别急着start mysql，先验证再启动
修复命令返回OK不代表表能用——它只说明文件结构被强行拉回可读状态：
- 启动前手动检查：
myisamchk -s /var/lib/mysql/mysql/user.MYI，确认不再报错 - 启动后立刻连上去：
mysql -u root -p -e "SELECT COUNT(*) FROM mysql.user;"，看能否正常查询 - 顺手把关联的
host、db、tables_priv都过一遍——它们常连锁损坏，漏一个下次还是起不来
真正麻烦的不是修复动作本身，而是修复后表逻辑是否自洽：比如USE_FRM模式重建的索引会丢失UNIQUE约束语义，--safe-recover提取的数据行顺序可能错乱。这些细节不会报错，但会在后续业务中悄悄引发主键冲突或权限失效。
