mysql启动失败应优先查看/www/server/data/localhost.err日志定位根因，而非盲目查端口；确认3306占用需netstat与lsof交叉验证；修复系统表须用安全模式启动并限制mysqlcheck范围；innodb损坏时按1–6级谨慎设置innodb_force_recovery。
MySQL 启动失败时先看 error.log 而不是直接查端口
宝塔面板里点“启动”没反应或立刻变“已停止”，大概率不是端口被占，而是 MySQL 进程根本没起来。这时候最该看的是 MySQL 错误日志：/www/server/data/*.err（通常是 /www/server/data/localhost.err）。日志里第一行报错往往就是根因——比如 InnoDB: Database page corruption、Table 'mysql.user' doesn't exist 或 Unknown table engine 'InnoDB'。这些都比端口问题更优先处理。
常见误导：看到面板提示“端口 3306 已被占用”，就去 kill -9 所有 mysqld 进程，结果导致表空间损坏加剧。真正需要杀进程的，是确认 MySQL 没在运行但端口仍被占（比如残留的 mysqld_safe 或其他程序）。
确认 3306 端口是否真被 MySQL 占用，用 netstat 和 lsof 交叉验证
只靠宝塔“端口检测”不准，它可能读取的是旧状态。实际检查必须进 SSH 执行：
netstat -tuln | grep :3306
如果输出为空，说明 3306 没被监听；如果有输出，记下 PID，再查进程：
lsof -i :3306
重点看 COMMAND 列是不是 mysqld。如果不是（比如是 python 或 node），才是真被其他程序占了；如果是 mysqld 但 MySQL 在宝塔里显示“未运行”，说明进程僵死，需手动 kill：
-
kill -15 <pid></pid>（温和终止） - 等 10 秒无响应再用
kill -9 <pid></pid> - 之后删掉
/www/server/data/mysql.sock（避免 socket 文件残留干扰）
修复损坏的系统表：用 mysqlcheck 前先确保 skip-grant-tables 不生效
很多教程让加 skip-grant-tables 修表，但在宝塔环境下极易引发权限混乱甚至无法登录 phpMyAdmin。正确做法是：先停 MySQL（宝塔里点“停止”），然后用安全模式启动单实例：
/www/server/mysql/bin/mysqld --defaults-file=/www/server/mysql/etc/my.cnf --user=mysql --skip-grant-tables --skip-networking &
注意三点：
- 必须指定完整
--defaults-file路径，否则读不到宝塔配置的innodb_force_recovery等关键项 -
--skip-networking防止外部连接，只允许本地 socket 访问 - 修完立刻
kill这个临时进程，再用宝塔正常启停，否则和面板服务冲突
连上后执行：mysqlcheck -r -u root mysql user db event proc（仅修复核心系统库，别全库扫）
InnoDB 表空间损坏时，innodb_force_recovery 的值不能乱设
如果日志里反复出现 InnoDB: Trying to access page number ... in space 0，说明 ibdata1 损坏。此时要在 /www/server/mysql/etc/my.cnf 的 [mysqld] 段加：
innodb_force_recovery = 1
从 1 试到 6，每改一次就尝试启动 MySQL：
- 1–2：跳过崩溃恢复，能启动但不能写入
- 3–4：忽略事务回滚，可能丢数据，但可导出
- 5–6：禁用撤回和前滚，仅限紧急导出，启动后立刻
mysqldump
切记：设了 >0 的值后，MySQL 会拒绝 INSERT/UPDATE/DELETE，且不能执行 DROP TABLE 或 ALTER TABLE。修完必须删掉这行再重启，否则后续写入全失败。
真正难处理的是 ib_logfile* 和 ibdata1 同时损坏，这时备份不可用就得重装 MySQL 并手动迁移 .frm + .ibd 文件——这种场景下，mysqlcheck 和 force_recovery 都无效，得靠 innodb_table_monitor 查结构再重建表。
