MySQL bind-address修改后netstat未显示0.0.0.0:3306，根本原因是服务未加载新配置，需确认实际生效的配置文件路径、检查是否启用skip-networking、同步配置mysqlx-bind-address，并重启服务而非reload。
bind-address 改了但 netstat 不显示 0.0.0.0:3306
改完 bind-address = 0.0.0.0 却没生效，第一反应不是配置写错了，而是服务根本没读到新配置。MySQL 启动时只加载一个主配置文件，而不同发行版默认路径不同：/etc/mysql/mysql.conf.d/mysqld.cnf（Ubuntu/Debian APT）、/etc/my.cnf（RHEL/CentOS）、/usr/local/mysql/etc/my.cnf（源码安装）。别只改了某个备份文件或用户目录下的 my.cnf。
确认是否真在用这个文件：
- 启动时加 --print-defaults 看实际加载路径：mysqld --print-defaults
- 或查进程参数：ps aux | grep mysqld，观察是否有 --defaults-file=...
- 修改后必须用 sudo systemctl restart mysql（Debian/Ubuntu）或 sudo systemctl restart mysqld（RHEL/CentOS），reload 不会重读 bind-address
skip-networking 被忽略导致 TCP 完全关闭
skip-networking 是比 bind-address 更彻底的开关：一旦启用，MySQL 直接不初始化任何 TCP socket，此时 bind-address 根本不参与决策。很多一键脚本、Docker 镜像或迁移时拷贝的老配置里就藏着它。
检查方式：
- 在所有可能的配置文件中搜索 skip-networking
- 若存在，确保它被注释（行首加 #）或显式设为 skip-networking = OFF
- MySQL 8.0+ 默认不启用，但 MariaDB 或某些定制包仍可能默认开启
mysqlx-bind-address 与 X Protocol 干扰客户端连接
MySQL 8.0+ 默认启用 X Protocol（用于 MySQL Shell、Connector/J 的 X DevAPI 模式等），它的监听地址由独立参数 mysqlx-bind-address 控制。如果该值仍是 127.0.0.1，而你的客户端（比如新版 JDBC 连接串含 ?allowPublicKeyRetrieval=true&useSSL=false&serverTimezone=UTC）自动尝试走 X Protocol，就会静默失败——连错误都不报，只卡住或抛模糊超时。
解决方法：
- 在 [mysqld] 段下添加或修改：mysqlx-bind-address = 0.0.0.0
- 或干脆禁用 X Protocol（如无需 JSON 表操作）：mysqlx=OFF
- 修改后同样需重启服务，且要验证：ss -tlnp | grep :33060（X Protocol 默认端口 33060）
防火墙、安全组和用户 host 权限三者缺一不可
即使 ss -tlnp | grep :3306 显示 *:3306，外部仍连不上，大概率卡在这三处：
- 防火墙：Ubuntu 的 ufw 默认拒绝所有入向；CentOS 的 firewalld 需运行 sudo firewall-cmd --add-port=3306/tcp --permanent && sudo firewall-cmd --reload
- 云服务器安全组：阿里云、腾讯云等控制台里必须手动放行 3306 入方向，且协议选 TCP，源 IP 不要填 0.0.0.0/0（生产环境应限制 CIDR）
- 用户权限：SELECT User, Host FROM mysql.user; 查目标用户（如 'appuser'）的 Host 值，'localhost' 和 '%' 是完全不同的账号；授权必须写成 GRANT ALL ON mydb.* TO 'appuser'@'%'，然后 FLUSH PRIVILEGES;
最容易被忽略的是：MySQL 的 bind-address 控制“能不能收包”，而 Host 字段控制“收了包认不认你”。两者都对了，才真正打通。
