必须先放行127.0.0.1的3306端口，再按需添加白名单，否则MySQL启动时自检失败；iptables规则顺序必须放行在前、拒绝在后，且云服务器需同步配置安全组与本地防火墙。
直接封 3306 端口是最容易出事的操作——MySQL 自己会连不上自己，服务根本起不来。 必须先放行 127.0.0.1，再按需加白名单，否则 mysqld 启动时初始化失败是常态。
iptables 规则顺序和本地回环必须写对
MySQL 启动时会主动连接 127.0.0.1:3306 做自检。如果 iptables INPUT 链里没有明确放行这条流量，mysqld 就卡在启动阶段，日志里可能只显示“Can’t connect to local MySQL server”。
- 正确顺序：先加放行规则，再加拒绝规则，且放行必须在前
- 必须包含：
iptables -A INPUT -s 127.0.0.1 -p tcp --dport 3306 -j ACCEPT - 白名单示例（只允许可信内网段）：
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 3306 -j ACCEPT - 最后兜底拒绝：
iptables -A INPUT -p tcp --dport 3306 -j DROP（注意用DROP，不是REJECT） - 别漏空格：
! -s写成!-s或!- s会导致规则无效
ufw 白名单配置比 iptables 更直观但默认策略要改
ufw 默认是「默认拒绝所有入向」，看起来安全，但实际会拦掉 127.0.0.1 的本地连接——因为 lo 接口不走 ufw 的普通规则链，得单独处理。
- 先确保 loopback 不被误杀：
ufw allow in on lo - 再加应用白名单：
ufw allow from 192.168.1.50 to any port 3306 - 或者更严格：
ufw allow from 192.168.1.50 to any port 3306 proto tcp - 启用前确认状态：
ufw status verbose，输出里必须看到Anywhere on eth0类似条目，而不是只有127.0.0.1相关 - 别跳过
ufw enable，否则规则不生效
云服务器上安全组和本地防火墙谁先生效
阿里云、腾讯云、AWS 的安全组是网络层第一道过滤，包还没进操作系统就可能被丢弃。也就是说：iptables 或 ufw 规则再细，安全组没开 3306，你连 telnet 公网IP 3306 都不通。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查安全组是否生效：从外网执行
telnet your-public-ip 3306，通了说明安全组已放行 - 查本地防火墙是否生效：在服务器本机执行
nc -zv 127.0.0.1 3306和nc -zv 192.168.1.50 3306（换为你的可信 IP），看响应是否一致 - 生产环境必须双控：安全组只放运维跳板机和应用服务器内网段，
iptables/ufw再做一层校验 - 安全组规则删了没人提醒，
iptables规则若已保存（如iptables-save > /etc/iptables/rules.v4）重启后还在——这点常被忽略
bind-address 和防火墙规则必须对齐
很多人设了 bind-address = 127.0.0.1 就以为万事大吉，结果防火墙却放开 3306 给外网——这等于门锁着，但把钥匙塞进邮筒。MySQL 根本不监听外网网卡，防火墙再怎么放行也没用；反过来，如果 bind-address = 0.0.0.0 却没配防火墙，就是裸奔。
- 验证当前监听地址：
netstat -tlnp | grep :3306，输出应为127.0.0.1:3306或具体内网 IP，不能是*:3306 - 运行中查配置：
mysql -e "SELECT @@bind_address;" - 开发机建议设
bind-address = 127.0.0.1+ 关闭防火墙的3306入向规则 - 跨机器调用必须放开
bind-address，此时防火墙白名单就是最后一道闸门
最容易被绕过的点其实是连接跟踪（conntrack）超时和 bind-address 的松动——MySQL 的 wait_timeout 可能设成 8 小时，而系统 conntrack 表默认只记 5 天，某些云主机内核甚至只记 30 分钟，导致长连接被静默断开，排查时容易误判为 MySQL 问题。
