必须填具体IPv4地址，不能写0.0.0.0或通配符；需在[mysqld]段显式配置如bind-address=192.168.1.100，并确认该IP真实存在、skip-networking已关闭、防火墙及云安全组放行对应端口。
bind-address 必须填具体 IPv4 地址，不能写 0.0.0.0 或通配符
MySQL 8.0 在多网卡服务器上不支持“选择性监听多个 IP”，但可以精确绑定到某一块网卡的 IPv4 地址。你必须在 mysqld.cnf 的 [mysqld] 段中显式写死一个已存在的、ip addr show 能查到的 IPv4 地址，例如：bind-address = 192.168.1.100。写成 0.0.0.0 就等于把所有网卡（包括 Docker bridge、Kubernetes CNI、甚至云厂商元数据接口）全打开，不是“监听特定 IP”，而是放弃控制。
常见错误现象：
-
bind-address = 192.168.1.*→ 启动失败，报unknown variable 'bind-address' -
bind-address = localhost→ 直接退出，MySQL 不认这个字符串 -
bind-address = ::1→ 无效，bind-address不处理 IPv6（X Plugin 才用mysqlx_bind_address）
确认目标 IP 真实存在且属于某块网卡
不能凭记忆或文档填 IP。必须先运行 ip addr show 或 hostname -I，从输出中挑出你要暴露的那个内网/专线网卡的实际地址。比如输出里有：
2: eth0: <broadcast>...
inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0
3: eth1: <broadcast>...
inet 10.0.2.15/24 brd 10.0.2.255 scope global eth1</broadcast></broadcast>
你想只让内网设备通过 eth0 连 MySQL，就填 192.168.1.100；想只让跳板机通过 eth1 连，就填 10.0.2.15。填错会导致 ss -tlnp | grep :3306 查不到监听，或者监听到了但连不上（因为路由没走对网卡）。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
改完配置后必须验证 socket 是否真绑定了该 IP
重启 mysql 服务后，唯一可信的验证方式是看系统级 socket 状态，而不是看配置文件有没有保存成功：
- 执行
sudo ss -tlnp | grep :3306 - 期望看到类似
192.168.1.100:3306或10.0.2.15:3306，而不是*:3306或[::]:3306 - 如果什么都没输出，说明 mysqld 没起来，查
journalctl -u mysql -n 50 -e - 如果看到
127.0.0.1:3306，说明配置没生效，检查是否写在了错误的配置段（必须是[mysqld]）、路径是否正确（Ubuntu 常用/etc/mysql/mysql.conf.d/mysqld.cnf，CentOS 常用/etc/my.cnf）
别漏掉 skip-networking 和防火墙这两道关
即使 bind-address 写对了，下面两个点任一出问题，连接照样失败：
-
skip-networking必须关闭：在配置文件中确保该行被注释或删除，否则 MySQL 彻底禁用 TCP/IP，ss命令查不到任何监听 - 系统防火墙必须放行该 IP 的 3306 端口：比如用
ufw allow from 192.168.1.0/24 to any port 3306 proto tcp，而不是笼统地ufw allow 3306（后者会暴露给所有来源） - 云服务器还要额外检查安全组——它优先级高于系统防火墙，哪怕 ufw 全开，安全组没放行，外部照样连不上
多网卡环境最容易忽略的是：你以为绑定了 192.168.1.100，结果客户端走的是另一条路由（比如默认网关不在该网段），导致连接超时却查不出原因。这时候得用 tcpdump -i eth0 port 3306 看包到底有没有进来。
