MySQL用户host字段支持IP、域名、通配符%和_,但仅做字符串匹配且不支持CIDR;'localhost'仅匹配Unix socket,'%'不匹配localhost;需配合bind-address、防火墙等网络配置才能生效。
MySQL 的用户权限不是只看用户名,host 字段才是决定“谁能在哪连上来”的关键。它不是 IP 白名单配置项,而是认证时与客户端发起连接的 host(即 TCP 连接来源的 IP 或主机名)做**精确匹配或通配符匹配**。
常见误区是以为 'user'@'192.168.%' 能匹配所有内网 IP,但实际它只匹配以 192.168. 开头的**字符串形式 host**——如果客户端用的是域名(如 db-server.local),或者 MySQL 服务端启用了 skip_name_resolve,那根本不会做 DNS 反查,host 就是连接时传过来的原始字符串,可能根本不是 IP。
'user'@'localhost':仅匹配 Unix socket 或明确指定 --host=localhost(且未走 TCP)的本地连接;它和 'user'@'127.0.0.1' 是两个完全不同的账号'user'@'%':匹配任意非 localhost 的 host 字符串(注意:不包括 localhost),但不等价于“允许所有 IP”,因为仍受网络层限制'user'@'10.0.0.5':只匹配该 IP 发起的连接;若客户端 NAT 后出口 IP 是 203.0.113.10,这个规则就失效'user'@'10.0.0.0/24'),只能用 % 或 _ 通配,且 % 不能跨段('10.%.%.%' 是合法的,但语义模糊、易误配)MySQL 默认只监听 127.0.0.1(Linux 下 bind-address = 127.0.0.1),这意味着即使你建了 'app'@'%',外部机器也连不上——TCP 层就拒绝了。这不是权限问题,是服务根本没在那个地址上收包。
skip-networking 更彻底:直接关闭 TCP/IP 协议栈监听,只留 socket,此时任何远程 IP 都无法建立连接,哪怕权限全开也没用。
bind-address = 0.0.0.0(监听所有 IPv4 接口)或具体内网 IP(如 10.0.0.10)sudo systemctl restart mysql(或 mysqld),仅 FLUSH PRIVILEGES 不生效Connection refused 或 Can't connect to MySQL server
MySQL 权限检查分两步:先查 mysql.user 表匹配 Us+
Host 元组,再查对应权限字段(如 Select_priv)。但这里有个关键细节:匹配是按 Host 字段长度降序进行的,更具体的 host 优先级更高。
比如同时存在 'app'@'10.0.0.5' 和 'app'@'%',从 10.0.0.5 连入时,永远命中前者,后者权限再大也无关。
GRANT 后无需手动 FLUSH PRIVILEGES(除非你直接改了 mysql 库的表)SELECT CURRENT_USER(), USER();,前者是匹配到的 User@Host,后者是客户端声明的,二者可能不同SELECT User, Host FROM mysql.user;,确认你要用的组合确实存在且拼写完全一致(注意空格、大小写、引号)权限宁可多建几个专用账号,也不要给一个账号 ALL PRIVILEGES ON *.*。网络层比数据库层更容易收敛风险。
SELECT,INSERT,UPDATE,DELETE,禁用 DROP、CREATE、FILE、PROCESS 等高危权限dba)限定 Host 为跳板机 IP 或运维网段(如 'dba'@'172.16.10.%'),绝不设为 %
ufw 或 iptables)只放行应用服务器和跳板机的 3306 端口,其他全部 DROPSELECT User, Host, Select_priv, Insert_priv, Drop_priv FROM mysql.user WHERE User = 'app' AND Host LIKE '10.%';
真正容易被忽略的是:MySQL 的 host 匹配发生在连接建立后、认证过程中,而网络可达性(bind-address、防火墙、路由)是前置条件。调权限前,先确认 telnet your-db-ip 3306 能通;否则所有 GRANT 都是空中楼阁。