MySQL默认端口3306是否真正生效需分层验证：先用ss或netstat确认操作系统层LISTEN状态及mysqld进程绑定，再执行SHOW VARIABLES LIKE 'port'核对服务内部实际端口值，最后检查错误日志中Bind on TCP/IP port等关键记录。
MySQL 默认端口 3306 是否真正生效，不能只看配置文件里写了 port = 3306，更不能只靠服务“启动成功”就认为端口可用。实际中大量故障源于端口没监听、被抢占、或配置未加载——必须分层验证。
确认 mysqld 进程是否在监听 3306（操作系统层）
这是第一道关卡：哪怕 MySQL 服务显示 active，mysqld 也可能根本没绑上端口。
- Linux/macOS 推荐用
sudo ss -tuln | grep :3306，看到LISTEN且users:(("mysqld",pid=...))才算真实监听 - Windows 用
netstat -ano | findstr :3306，需管理员权限；若输出含LISTENING和 PID，再用tasklist | findstr "PID"确认是mysqld.exe - 常见假阳性：
netstat显示 3306 被占，但 PID 对应的是旧 MySQL、MariaDB 或 Node.js 服务——得杀错进程，不是重启 MySQL - 如果无任何输出，先查
systemctl status mysql（Linux）或服务管理器（Windows），再查my.cnf里是否误配了skip-networking = 1或bind-address = 127.0.0.1却被防火墙拦截
验证 MySQL 实际使用的端口值（服务内部层）
配置文件写对了，不等于 MySQL 启动时读取成功。有些语法错误或路径错误会导致它静默回退到默认 3306，但你改的端口根本没生效。
- 连上 MySQL 后执行
SHOW VARIABLES LIKE 'port';，返回的Value必须是你期望的数字（比如 3306 或你改的 3307） - 如果返回
0，说明启用了skip-networking，TCP 连接被彻底禁用，此时只能走 socket 文件 - 别信
SELECT @@port;—— 它和SHOW VARIABLES等效，但容易和@@port_number等混淆，坚持用标准写法 - 配置文件位置必须准确：
/etc/my.cnf（Linux）、/usr/local/etc/my.cnf（macOS Homebrew）、C:\ProgramData\MySQL\MySQL Server X.X\my.ini（Windows），改错文件等于白改
检查 MySQL 错误日志里的端口绑定记录（调试依据）
终端没报错 ≠ 没问题。端口冲突时，MySQL 常静默降级或跳过绑定，只在错误日志里留一行警告。
- 日志路径通常在
datadir下的hostname.err文件里（如/var/lib/mysql/yourhost.err） - 搜索关键词：
Starting MySQL、Bind on TCP/IP port、Address already in use、Can't start server - 典型错误信息：
Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use—— 这个98就是端口冲突铁证 - Docker 或云环境要额外看容器日志：
docker logs mysql-container，因为my.cnf可能被-p 3306:3307覆盖
最容易被忽略的点：改完端口后，所有客户端连接命令都必须显式加 -P3307（注意大写 P），漏掉就默认连 3306，报错时还以为是服务没起来。而 MySQL 本身不会提醒你“你连错了端口”，它只会安静拒绝。
