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默认值和云平台安全组配置。
