MySQL白名单本质是用户Host字段匹配，需CREATE USER时显式指定IP或网段，GRANT必须与Host完全一致；Host不可UPDATE修改，不支持CIDR，须配合防火墙与bind-address分层防护。
MySQL 没有独立的“IP白名单开关”，所谓白名单，本质是用户账号的 Host 字段匹配逻辑。配置错误时，你看到的不是“白名单没生效”，而是 Access denied for user 'xxx'@'yyy' —— 这说明连接已抵达 MySQL，但账号不认这个来源 IP。
CREATE USER 时必须显式指定 Host，不能靠后期补救
MySQL 的 Host 是账号身份的一部分，创建后不可 UPDATE 修改（尤其在 8.0+ 版本中，直接改 mysql.user 表会破坏密码哈希、权限缓存，甚至报错 ERROR 1470 (HY000)）。
- 正确做法：先查旧账号
SELECT User, Host FROM mysql.user WHERE User = 'app';，再用完整名称DROP USER 'app'@'old_host';删除（注意必须带@'host'，只写DROP USER 'app'在 8.0+ 会失败） - 重建时严格指定目标 IP 或网段：
CREATE USER 'app'@'10.0.2.50' IDENTIFIED BY 'pwd';或CREATE USER 'app'@'10.0.2.%' IDENTIFIED BY 'pwd'; -
Host不支持 CIDR（如'10.0.2.0/24'是非法语法），也不支持正则；%和_是仅有的通配符
GRANT 必须与 CREATE USER 的 Host 完全一致
GRANT 不会自动创建用户（MySQL 8.0+ 默认关闭 NO_AUTO_CREATE_USER），它只授予权限。Host 不匹配会导致授权失败，且不会报“用户不存在”，而是报 ERROR 1410 (42000): You are not allowed to create a user with GRANT。
- 错误示例：
CREATE USER 'app'@'10.0.2.50'...，却执行GRANT ... TO 'app'@'10.0.2.%'→ 失败 - 正确顺序：建用户 → 授权 → 刷新：
GRANT SELECT ON mydb.* TO 'app'@'10.0.2.50'; FLUSH PRIVILEGES; - 本地访问需单独处理：
'app'@'localhost'和'app'@'127.0.0.1'是两个账号，Unix socket 和 TCP 走不同路径
bind-address 和防火墙才是第一道拦截线
如果客户端连不上，90% 不是 MySQL 权限问题，而是更外层被拦住了。报 Connection refused 或超时，基本可排除 Host 字段问题。
-
bind-address = 127.0.0.1→ 外部 IP 根本连不到 3306 端口，Host再精确也无意义 - 云数据库（如阿里云 RDS）默认忽略
mysql.user中的Host，白名单必须在控制台安全组里配 - 宿主机防火墙（
iptables/ufw）或 Docker 映射限制（如-p 10.0.2.10:3306:3306）比 MySQL 层级更早生效
多 IP 场景下别偷懒，一个 IP 一个账号最稳妥
想放通 10.0.2.10、10.0.2.25、10.0.2.100？别写 'app'@'10.0.2.%' —— 这等于把整个 /24 都放开，失去白名单意义。
- 精确做法：建三个账号：
CREATE USER 'app'@'10.0.2.10'...、CREATE USER 'app'@'10.0.2.25'...、CREATE USER 'app'@'10.0.2.100'...，再分别GRANT - 避免
'app'@'%.%.%.%'或'app'@'10.%'这类宽泛写法，% 在开头或中间会极大扩大匹配范围 - 生产环境真正有效的防护是分层：安全组/防火墙（最外层）→
bind-address（中间层）→Host字段（最内层校验）
最容易被忽略的一点：MySQL 的 Host 匹配的是客户端 TCP 包里的真实源 IP，不是你本机 ifconfig 看到的地址，也不是代理或 NAT 后的地址。如果你走的是跳板机、K8s Service 或云 LB，得确认最终抵达 MySQL 的 IP 是什么，再决定怎么设 Host。
