MySQL 5.7 启动后显示 active (running) 但无法连接，本质是 systemd 仅检测进程 fork 成功，未验证初始化完成；真实原因常为系统表缺失、端口被占或 libaio 等依赖库缺失，需查 localhost.err 日志末尾、用 lsof 和 ldd 交叉验证。
MySQL 5.7 启动后显示 active (running) 但实际无法连接，不是真运行，而是卡在初始化或权限校验阶段——这种“假死”最常由系统表缺失、端口静默占用或依赖库缺失导致。
为什么 systemctl status 显示 running 却连不上？
systemd 只判断 mysqld 进程是否 fork 出来，并不验证它是否完成初始化。常见假死表现：
- 执行
mysql -u root -p报错Can't connect to local MySQL server through socket -
netstat -tuln | grep :3306没输出，说明 mysqld 根本没监听 - 日志里出现
Can't open and lock privilege tables: Table 'mysql.user' doesn't exist
根本原因：mysqld 启动流程卡在数据目录校验环节，进程未退出但也没继续——systemd 就认为它“活”着。
查 error log 是唯一可靠入口
别信状态，直接看日志。宝塔用户路径通常是 /www/logs/mysqld.log 或 /www/server/mysql/data/localhost.err；标准安装则查 /var/log/mysqld.log 或 /var/lib/mysql/hostname.err。
重点关注三类报错：
-
Table 'mysql.user' doesn't exist→ 数据目录未初始化或版本混用 -
error while loading shared libraries: libaio.so.1→ 缺libaio（CentOS 7 最常见） -
Address already in use→ 端口被占，但 mysqld 写完日志就退出，systemd 不感知
执行 tail -n 50 /path/to/localhost.err，从末尾往前翻，最后一段才是真实失败点。
验证配置和依赖是否真就绪
光改配置文件不够，得让 mysqld 自己验证：
- 运行
mysqld --validate-config --defaults-file=/etc/my.cnf，返回 0 才算语法过关 - 检查动态库：执行
ldd /usr/sbin/mysqld | grep "not found"，缺libaio或numactl必须装全 - 确认端口空闲：
sudo lsof -i :3306，注意 Docker 容器也可能绑定宿主机 3306
特别提醒：宝塔面板安装时若卡在“正在安装…”，大概率是 libaio 或 numactl 缺失，install.log 里会停在 mysqld --initialize 前。
数据目录异常时别直接删 whole data 目录
看到 mysql.user doesn't exist 就删整个 data 目录，容易丢业务表。正确做法分两步：
- 先停服务：
systemctl stop mysqld - 只删系统库相关文件：
rm -f /var/lib/mysql/mysql /var/lib/mysql/performance_schema /var/lib/mysql/sys - 再用对应版本初始化：
mysqld --initialize --user=mysql --datadir=/var/lib/mysql
旧业务库（如 your_db）的 .ibd 和 .sdi 文件保留不动，初始化后它们会自动识别。混用 5.6 和 5.7 的 data 目录会导致升级校验失败，比删库更难恢复。
假死问题最麻烦的地方在于：日志可能被覆盖、systemd 状态有误导、错误堆栈藏在中间行——必须盯住 localhost.err 最后 20 行，配合 lsof 和 ldd 交叉验证，而不是反复重启服务。
