MySQL启动失败但日志无端口冲突时，大概率是内存不足触发OOM killer杀掉进程；需用dmesg查OOM记录、free看可用内存，并调小innodb_buffer_pool_size。
MySQL 启动失败但日志里没报端口冲突
宝塔面板显示 MySQL 启动失败，systemctl status mysqld 看状态是 failed，但 /www/server/mysql/data/*.err 日志里既没出现 Address already in use，也没提端口被占——这时候大概率不是端口问题，而是内存不足触发了内核 OOM killer 杀掉了 mysqld 进程。
实操建议：
- 先查系统日志：
dmesg -T | grep -i "killed process" | grep mysqld，如果看到类似Killed process 12345 (mysqld) total-vm:2.1g, anon-rss:1.3g，就是 OOM 了 - 检查可用内存：
free -h，重点看available列；小内存机器（比如 1G RAM）跑 MySQL 5.7+ 默认配置基本必崩 - 临时缓解：在
/etc/my.cnf的[mysqld]段下加innodb_buffer_pool_size = 64M（1G 机器建议值），再systemctl restart mysqld
netstat 查不到 3306 却还是启动不了
netstat -tuln | grep :3306 或 lsof -i :3306 返回空，不代表端口就空闲——MySQL 启动时会尝试绑定 0.0.0.0:3306 和 :::3306（IPv6），而有些工具默认不显示 IPv6 监听。更关键是：MySQL 启动失败可能根本没走到 bind 阶段，比如数据目录权限不对、ibdata1 损坏、或 skip-networking 被意外启用。
实操建议：
- 用
ss -tuln | grep -E ':3306|:::3306'替代 netstat，它对 IPv6 更敏感 - 确认数据目录归属：
ls -ld /www/server/mysql/data，必须是mysql:mysql，否则启动直接静默退出 - 检查是否误启了
skip-networking：在/etc/my.cnf里搜这一行，有就删掉或注释
修改 my.cnf 后重启仍不生效
改完 /etc/my.cnf，systemctl restart mysqld，但 mysql -e "show variables like 'innodb_buffer_pool_size';" 显示的还是旧值——常见原因是宝塔自己维护了一套配置加载逻辑，它可能优先读取 /www/server/mysql/etc/my.cnf，或者把你的修改覆盖了。
实操建议：
- 确认 MySQL 实际加载的配置文件：
mysql --help | grep "Default options"，输出末尾那行才是真实路径 - 宝塔用户优先改
/www/server/mysql/etc/my.cnf，改完别忘了chown mysql:mysql /www/server/mysql/etc/my.cnf - 验证配置是否被识别：
mysqld --defaults-file=/www/server/mysql/etc/my.cnf --verbose --help | grep buffer_pool，看输出里是不是你设的值
启动卡在 “Starting MySQL” 不报错也不成功
面板上进度条停在 “Starting MySQL”，systemctl status mysqld 显示 activating (start) 卡住，journalctl -u mysqld -n 50 -f 也刷不出新日志——这通常是初始化脚本等待某个条件超时，最常见的是磁盘 I/O 极慢（比如低配云服务器挂了机械盘或共享 SSD），或 SELinux 强制拦截了文件访问。
实操建议：
- 临时关 SELinux 测试：
setenforce 0，再试启动；若恢复则需调整策略，而非永久关闭 - 检查磁盘响应：
dd if=/dev/zero of=/tmp/test bs=1M count=1024 oflag=direct，看写入速度是否低于 5MB/s（太慢会影响 InnoDB 初始化） - 强制跳过崩溃恢复（仅限数据已备份）：在
[mysqld]下加innodb_force_recovery = 1，从 1 试到 6，启动成功后立刻导出数据
内存和磁盘 I/O 是这类“无错误卡死”最常被忽略的两个点，尤其是用宝塔一键部署在廉价 VPS 上时，配置文件调得再准，硬件拖后腿也白搭。
