MySQL报错MY-013942，钥匙文件打不开导致故障，远程帮忙修复方案分享

（引用自知乎专栏“DBA运维笔记”） 那天晚上正准备下班，手机突然收到一条紧急告警，提示线上的一台核心MySQL数据库实例宕机了，心里一紧，赶紧连上服务器查看日志，在密密麻麻的错误信息里，最显眼的就是这一行报错：MY-013942 - Can‘t open file: ’./mysql/user.MYI’ (errno： 135)，当时第一反应就是，钥匙文件出问题了。

这个“钥匙文件”，其实就是MySQL用来快速查找数据的一种索引文件，你可以把它想象成一本字典的目录，现在目录页被撕坏了或者打不开了，数据库自然就找不到用户权限这些关键信息，服务崩溃也就不可避免，errno 135这个错误代码，通常指向的是索引文件头信息损坏或者文件本身出现了不可读的物理问题。

（引用自CSDN博客“数据库故障排查实录”） 遇到这种问题，千万别慌，更不要想着去重启服务碰运气，很可能直接导致数据彻底损坏，正确的做法是遵循一套清晰的排查流程，第一步肯定是先确认数据库进程是否已经完全停止，如果它还在挣扎运行，我们首先要做的是安全地停止它，可以使用mysqladmin -u root -p shutdown这个命令来尝试正常关闭，但如果数据库已经无响应，这个命令可能失效，这时候就不得不使用kill命令来强制结束进程了，这里有个关键点，（引用自MySQL官方文档常见问题章节） 官方建议优先尝试使用kill命令发送一个TERM信号（比如kill -15 <mysql_pid>），给进程一个清理现场的机会，只有在万不得已的情况下，才使用kill -9这种强硬手段，因为kill -9可能会造成更严重的数据不一致。

停止MySQL服务之后,第二步是进行关键文件的备份，这是整个修复过程中最重要的一步，相当于上了个保险，无论后续操作成功与否，原始数据都不会被破坏，我们需要找到MySQL的数据目录（通常叫data或mysql-data），然后把这个目录完整地打包压缩一份，比如可以执行tar -zcvf mysql_data_backup.tar.gz /var/lib/mysql，有了这个备份，心里就踏实多了。

（引用自知乎专栏“DBA运维笔记”） 备份完成，接下来就是针对损坏的索引文件进行修复，MySQL很贴心地提供了一个修复工具叫myisamchk，因为报错信息指向的是user.MYI文件，这个文件属于mysql系统数据库下的user表，而这张表默认是MyISAM引擎的，所以用这个工具正合适，修复前，需要确保没有进程在访问这些文件，所以服务必须是停止状态，进入mysql数据库所在的物理目录，通常是/var/lib/mysql/mysql/，先执行myisamchk -e user来检查一下表的错误情况，工具会输出详细的检查报告，确认问题后，再执行myisamchk -r user来进行修复，参数-r代表恢复（recover），它会尝试从数据文件中重建索引，如果-r效果不理想，还可以尝试更强大的-o选项，即myisamchk -o user，这个选项会使用一个更慢但更安全的修复算法。

（引用自CSDN博客“数据库故障排查实录”） 仅仅修复user表可能还不够，因为这次损坏可能不是孤立的，为了保险起见，最好对mysql系统库下的所有表都进行一次检查，可以先用myisamchk -e *.MYI检查所有MyISAM表，然后再用myisamchk -r *.MYI进行批量修复，这个过程可能会花点时间，但能确保系统库的完整性，修复完成后，就是激动人心的重启时刻了，用systemctl start mysqld或者service mysql start命令启动MySQL服务，这时要紧盯错误日志，通常路径是/var/log/mysqld.log，如果日志中没有再出现类似的致命错误，并且服务状态显示为active (running)，那么恭喜你，修复基本成功了，最后一步，不要忘记验证，用原来的账号密码连接一下数据库，执行SHOW DATABASES；看看数据库列表是否正常，再USE mysql； SELECT User， Host FROM user；看看用户权限表能不能正常查询，一切顺利的话，这场故障就算成功解决了。

（引用自知乎专栏“DBA运维笔记”） 事后复盘同样重要，为什么好端端的索引文件会突然损坏？常见的原因有几个：服务器突然断电是最常见的元凶；还有就是服务器在IO负载极高的情况下被强制重启；磁盘有坏道或者内存故障这种硬件问题也会导致文件损坏，除了掌握修复方法，建立一个稳定的供电环境，配置不间断电源（UPS），定期做硬件健康检查，这些预防措施才是避免问题发生的根本，这次故障也提醒我们，定期备份并验证备份的有效性，是DBA工作中最不能偷懒的一环。