mysql用户账号的host字段用于匹配客户端声明的主机名或IP，非IP列表；应填具体IP、网段通配符（如’192.168.1.%’）、域名模式（如’%.example.com’）、’localhost’或’%’，生产禁用’%’。
MySQL 用户账号的 host 字段到底填什么
MySQL 的权限控制核心在于 user 表里的 host 字段，它不是“允许访问的 IP 列表”，而是用于**匹配客户端连接时声明的主机名或 IP 地址**。填错会导致权限不生效或过度开放。
-
'192.168.1.100'：只允许该 IP 直连（IPv4） -
'192.168.1.%'：匹配 192.168.1.0/24 网段（注意不是 CIDR，% 是通配符，不能跨字节） -
'%.example.com'：匹配任意子域名（需 dns 可解析，且客户端未用 IP 连接） -
'localhost'：仅限 unix socket 或 127.0.0.1（取决于 MySQL 配置），和'127.0.0.1'是两个不同账号 -
'%'：允许任意主机连接（含公网）——生产环境禁止直接使用
创建带 IP 限制的用户要分两步走
不能只靠 CREATE USER 一步到位，必须显式指定 host 并授权，否则默认 host 是 '%'，等于放行所有来源。
正确做法：
CREATE USER 'app_user'@'10.20.30.40' IDENTIFIED BY 'strong_pass'; GRANT select, INSERT ON mydb.orders TO 'app_user'@'10.20.30.40';常见错误：
- 执行
CREATE USER 'app_user'@'%' IDENTIFIED BY '...';后再GRANT ... TO 'app_user'@'10.20.30.40'—— 权限不会自动绑定到新 host，MySQL 会报错 “no such user” - 忘记
FLUSH PRIVILEGES;：修改mysql.user表后才需要；但用CREATE USER/GRANT语句操作，权限立即生效，无需刷新
如何验证当前连接匹配的是哪个账号
登录后执行 SELECT USER(), CURRENT_USER();：
-
USER()返回客户端声明的身份（如app_user@10.20.30.41） -
CURRENT_USER()返回实际匹配的权限账号（如app_user@10.20.30.40）
如果两者不一致，说明你连进去了，但没走预期的权限规则——很可能是 host 匹配失败，降级到了更宽泛的账号（比如 'app_user'@'%'），或者 DNS 解析把 IP 转成了 hostname 导致匹配偏差。
排查建议：
- 查匹配顺序：
SELECT host,user FROM mysql.user ORDER BY host DESC;—— MySQL 按最长前缀匹配，'10.20.30.40'优先于'10.20.30.%'，而'%'排最后 - 禁用 DNS 反解（避免 hostname 匹配干扰）：启动 mysqld 时加
--skip-name-resolve，并确保所有host值都是 IP 或'%'
防火墙与 bind-address 不是 MySQL 权限，但决定能不能连上
MySQL 层面的 IP 限制生效前提：连接请求得先抵达 mysqld。这依赖两个外部控制点：
-
bind_address配置（在my.cnf中）：设为127.0.0.1就只监听本地；设为0.0.0.0才监听所有接口 —— 但即使绑定了0.0.0.0，仍受user.host限制 - 系统防火墙（如 iptables/nftables）：必须放行目标端口（默认 3306），否则连接在 TCP 层就被拒了，MySQL 根本收不到请求
典型误判场景：用户改了 user.host 却发现还是连不上，其实是 bind_address 仍为 127.0.0.1，或云服务器安全组没开 3306 入方向。
真正做最小权限时，这三层（防火墙 → bind_address → user.host）要逐层收紧，缺一不可。最容易被忽略的是 bind_address 默认值和云平台安全组配置。