MySQL启动失败因ibdata1损坏或ib_logfiles不匹配，需先备份datadir、设innodb_fast_shutdown=0强制安全关机再启动恢复；无有效备份时不可盲目启用innodb_force_recovery。
MySQL 启动失败报错 ibdata1 损坏或日志文件不匹配
宝塔面板里点“启动”没反应，或者日志里反复出现类似 InnoDB: The log sequence number in ibdata1 does not match the log sequence number in the ib_logfiles 或 ibdata1 is corrupt 的错误——基本就是 InnoDB 的共享表空间或重做日志（ib_logfile0/ib_logfile1）状态不一致，MySQL 拒绝启动以保数据安全。
别急着删文件或重装。InnoDB 有恢复机制，但必须按顺序操作，跳步或乱删会直接丢库。
- 先确认 MySQL 是否真在运行：
ps aux | grep mysql，避免重复启动冲突 - 去宝塔「数据库」→「配置文件」，记下
datadir路径（通常是/www/server/data），所有操作都基于这个目录 - 停止 MySQL：用宝塔界面停，或命令
systemctl stop mysqld（不是mysql） - 备份整个
datadir目录（哪怕只剩 5 分钟，也先cp -r /www/server/data /www/server/data.bak）
手动清理 ib_logfile* 前必须关掉 innodb_fast_shutdown
很多人直接删 ib_logfile0 和 ib_logfile1，结果重启还是报错。根本原因是 MySQL 关机时没把脏页刷完，日志头尾对不上。强行删日志文件等于让 InnoDB “失忆”，它无法回滚未提交事务。
正确做法是让 MySQL 自己清日志：改配置强制干净关机。
- 编辑 MySQL 配置文件（宝塔里「数据库」→「配置修改」，或直接改
/etc/my.cnf） - 在
[mysqld]下加一行：innodb_fast_shutdown = 0 - 保存后执行：
systemctl start mysqld—— 此时 MySQL 会尝试正常恢复，如果成功，日志自动重建，ib_logfile*会被覆盖 - 启动成功后，再删掉这行配置，避免后续关机变慢
ibdata1 真损坏了怎么办？别碰 innodb_force_recovery 除非你有备份
ibdata1 是 InnoDB 的核心共享表空间，存着数据字典、undo 日志、系统表等。一旦报 corrupt，说明底层结构已不可信。网上一堆教设 innodb_force_recovery = 1~6 然后导出数据，但实际中：设成 1–2 可能能启，但多数情况到 3 就卡死；设到 4 以上，MySQL 连 SELECT 都禁掉，mysqldump 直接失败。
真正能救回来的路径只有一条：
- 确认你有最近的
mysqldump备份（宝塔「数据库」→「备份」里导出的 .sql 文件） - 没有备份？检查
/www/server/data下有没有mysql库和业务库的子目录，里面每个.ibd文件对应一张独立表（需开启innodb_file_per_table=1） - 如果有
.ibd文件且没被删，可尝试用mysqlfrm或 Percona 的innodb-tools提取建表语句，再配空库导入，但成功率低、耗时长 - 没备份也没
.ibd？停手。重装 MySQL + 恢复备份是唯一稳妥方案
修复后 MySQL 启动了，但网站连不上数据库
常见错觉：“MySQL 启动成功 = 一切正常”。其实宝塔里服务状态绿了，不代表监听端口通、用户权限对、socket 路径一致。
- 检查 MySQL 是否监听本地：
netstat -tlnp | grep :3306，如果只有127.0.0.1:3306，远程连接会失败（但宝塔和本地 PHP 通常没问题） - 进 MySQL 执行：
SELECT user,host FROM mysql.user;，确认root@localhost存在且密码没被意外重置（宝塔有时升级会重置 root 密码） - PHP 连接报
Can't connect to local MySQL server through socket？看phpinfo()里mysqli.default_socket值，对比 MySQL 配置里的socket路径（常为/tmp/mysql.sock或/www/server/data/mysql.sock），不一致就改 PHP 配置或 MySQL 配置 - 宝塔里「数据库」列表为空？重启宝塔：
bt restart，它会重新扫描datadir
最麻烦的其实是 ibdata1 损坏后，即使启动成功，某些表可能已半损坏——查数据时突然报 Table 'xxx' doesn't exist 或 Incorrect key file。这种没法靠重启解决，得逐个 CHECK TABLE，修不了就只能从备份恢复单表。
