MySQL访问控制核心是mysql.user表中host字段的匹配规则，而非防火墙或bind_address；需结合bind_address限制监听、host限定用户来源、防火墙/安全组控制网络层访问，并避免直接UPDATE权限表。
MySQL 用户账户的 host 字段决定能否从指定 IP 连接
MySQL 的访问控制核心不在防火墙或配置文件，而在于 mysql.user 表中每个用户的 host 值。它不是“白名单开关”，而是连接匹配规则：客户端发起连接时，MySQL 会按 user@host 组合逐行匹配权限表，取最具体的匹配项（比如 'app'@'192.168.1.100' 优先于 'app'@'%'）。
常见误区是以为改了 bind_address 或开了防火墙就等于限制了 IP —— 实际上只要用户被建为 'user'@'%'，且密码正确，任何能连到 MySQL 端口的 IP 都能登录。
- 新建受限用户：用
CREATE USER 'api'@'10.0.5.22'明确指定单 IP，或'report'@'192.168.10.%'匹配子网 - 禁止通配符滥用：避免
GRANT ... ON *.* TO 'admin'@'%'，生产环境应限定 host - 检查现有宽松账户：
SELECT User, Host FROM mysql.user WHERE Host = '%';
- 修改已有用户 host：
RENAME USER 'old'@'%' TO 'old'@'172.16.3.45';（注意：不能直接 UPDATE 表，必须用 RENAME 或 DROP+CREATE）
mysqld 配置中的 bind_address 和 skip-networking 影响监听范围
bind_address 控制 mysqld 进程绑定哪个网卡地址，默认值 127.0.0.1 意味着只接受本地 socket 或 localhost TCP 连接，外部 IP 根本连不上 —— 这是最基础的网络层隔离，比账号 host 更前置。
若需允许远程访问，必须显式设为 0.0.0.0（所有 IPv4 接口）或具体内网 IP（如 192.168.2.10），但此时务必配合严格的 user@host 策略，否则等于裸奔。
- 仅允许内网访问：
bind_address = 192.168.2.10
，并确保防火墙放行该 IP 的 3306 端口 - 完全禁用 TCP（仅 socket）：
skip-networking = 1
，适合纯本地应用，但mysql -h 127.0.0.1会失败（走 TCP），必须用-S /var/run/mysqld/mysqld.sock - IPv6 注意：
bind_address = ::同时监听 IPv6，若只需 IPv4，别写成0.0.0.0,::，否则可能绕过预期限制
防火墙与云平台安全组是必要补充，不是替代方案
MySQL 自身不校验来源 IP 的合法性，host 字段只是权限匹配依据；真实网络流量是否抵达 mysqld，取决于操作系统防火墙和云厂商安全组。两者缺一不可。
例如：你已将用户设为 'web'@'10.0.1.5'，但服务器防火墙未开放 3306 端口，或阿里云安全组没放行该 IP，连接仍会超时（而非报错 “Access denied”）。
- Linux iptables 示例（仅允特定 IP）：
iptables -A INPUT -p tcp --dport 3306 -s 10.0.1.5 -j ACCEPT iptables -A INPUT -p tcp --dport 3306 -j DROP
- 云平台操作重点：确认安全组规则作用在**数据库实例所在服务器的网卡**，而不是跳板机或 LB；入方向规则目标端口填 3306，源地址填 CIDR（如
10.0.1.5/32） - 测试连通性顺序：先
telnet db-host 3306看端口通不通，再尝试 mysql 客户端登录 —— 区分是网络层拦截还是权限层拒绝
动态刷新权限后记得 flush privileges，但多数情况不需要
修改 mysql.user 表（如 INSERT/UPDATE/DELETE）后，必须执行 FLUSH PRIVILEGES; 才能让变更生效。但使用 CREATE USER、GRANT、DROP USER 等 DDL 语句时，MySQL 会自动重载权限表，无需手动 flush。
容易踩坑的是：有人用 UPDATE mysql.user SET Host='10.0.1.5' WHERE User='app'; 改完不 flush，结果权限一直不生效，还以为是语法或缓存问题。
- 安全起见，执行完 DML 类权限修改后，加一句：
FLUSH PRIVILEGES; - 避免直接 UPDATE 权限表：字段逻辑复杂（如
authentication_string加密方式、password_expired状态），推荐始终用 GRANT/REVOKE - 权限变更对已建立连接无效：新权限只影响后续新连接，当前连接维持原有权限直到断开
实际部署中最容易被忽略的，是 bind_address 和 user@host 的双重约束关系 —— 少一个环节，整个白名单就形同虚设。
