根本原因是残留mysqld进程或文件锁导致端口不可复用，而非真实端口被占；应优先查ps aux | grep mysqld和sudo lsof +d /var/lib/mysql/，而非仅依赖netstat。
MySQL 重启失败并提示 Address already in use，根本原因不是端口“真被别的程序占着”，而是 MySQL 进程没彻底退出，或者系统内核还把 3306（或你配置的端口）标记为不可复用状态——最常见的是残留进程、TIME_WAIT 残留、或 mysqld 实例卡在僵死状态。
为什么 netstat 查不到占用，但 MySQL 还是起不来？
这是最容易误判的点。很多人执行 netstat -tuln | grep :3306 或 lsof -i :3306 没输出，就以为端口空闲，其实可能：
-
mysqld进程仍在后台运行（比如 systemd 没杀干净、或用了mysqld_safe自动拉起），只是没监听 socket —— 此时lsof不显示，但 InnoDB 文件锁（如ibdata1）仍被持有，导致新实例无法初始化 - 旧连接处于 TCP 的
TIME_WAIT状态（虽然不常见于服务端监听端口，但若 MySQL 被配置为客户端频繁连自己、或启用了skip-networking=OFF+ 大量短连接，也可能触发内核端口复用限制） - SELinux 或 AppArmor 静默拦截 bind 操作，错误日志里只写 “
Address already in use”，但实际是权限拒绝，不是端口冲突
怎么快速确认是不是残留 mysqld 进程？
别只查端口，直接查进程和锁文件：
- 运行
ps aux | grep mysqld，看有没有除grep本身外的mysqld或mysqld_safe进程 - 检查数据目录下关键文件是否被占用：
sudo lsof +D /var/lib/mysql/ 2>/dev/null | grep -E "(ibdata1|ib_logfile|mysql.sock)" - 如果看到
mysqld进程在跑，但systemctl status mysqld显示 inactive，说明 systemd 管理脱节了，得先sudo kill -9 <pid></pid>再清理
bind 失败时 error log 里真正该盯住的几行
MySQL 的 error.log（路径可通过 grep -i log_error /etc/my.cnf 找）比终端报错靠谱得多。重点关注这些原始线索：
-
Can't start server: Bind on TCP/IP port: Address already in use→ 真端口冲突，继续查lsof -i :3306 -
InnoDB: Unable to lock ./ibdata1 error: 11→ 不是端口问题，是还有个 mysqld 在用数据文件 -
Starting MySQL... ERROR! The server quit without updating PID file→ PID 文件残留（如/var/run/mysqld/mysqld.pid），删掉再试 -
World-writable config file '/etc/my.cnf' is ignored→ 配置文件权限太宽，MySQL 直接跳过它，按默认值启动，可能连错 datadir 或 port
为什么加了 SO_REUSEADDR 还不管用？
MySQL 本身不暴露 socket 层 API，SO_REUSEADDR 是应用层（比如你自己写的 TCP 服务）调用 setsockopt() 设置的。MySQL 不走这条路——它依赖内核对 bind() 的行为判断。所以：
- 你不能靠改 MySQL 源码或配置项来开启
SO_REUSEADDR - 唯一等效做法是：确保没有其他 mysqld 实例在跑，且数据文件未被锁定；或者换端口（在
[mysqld]段加port = 3307） - 若必须复用 3306，可临时调大内核参数（不推荐生产）：
echo 1 | sudo tee /proc/sys/net/ipv4/tcp_fin_timeout（仅缩短 TIME_WAIT，治标）
真正卡住 MySQL 启动的，90% 是残留进程 + 文件锁，不是网络协议栈问题。查 ps 和 lsof +D /var/lib/mysql 比反复 netstat 有效得多。
