能，GRANT 支持 IP 段字符串通配如 '192.168.1.%'，但仅作前缀匹配而非子网匹配，不支持 CIDR；需禁用 DNS 解析（skip_name_resolve=ON）并确保客户端使用 IP 连接。
GRANT 语句里用 IP 段通配符（如 192.168.1.%）能生效吗？
能，但仅限于标准的主机名通配规则，不支持 CIDR（如 192.168.1.0/24）或子网掩码语法。MySQL 的 GRANT 对 HOST 参数只认两种模式：精确匹配（如 '192.168.1.10'）和简单通配（% 或 _），其中 % 匹配任意长度字符串（包括空），_ 匹配单个字符。
所以 '192.168.1.%' 是合法且常用的做法，它会匹配 192.168.1.1、192.168.1.255，甚至 192.168.1.123abc（如果 DNS 反解出这种名字）——这本身已是隐患。
-
'192.168.1.%'→ 匹配所有以192.168.1.开头的 IPv4 地址或主机名（注意：不是“该网段”，而是“字符串前缀”） -
'192.168.%.%'→ 表面想覆盖192.168.x.y，但也会误放192.1680.1.1（因为%不限制位数） -
'192.168.1.0/24'→ 直接报错：ERROR 1133 (HY000): Can't find any matching row in the user table，MySQL 根本不解析 CIDR
为什么 GRANT ... ON *.* TO 'u'@'192.168.1.%' 有时连不上？
常见原因不是语法错，而是 MySQL 的主机名解析逻辑在作祟。默认开启 skip_name_resolve=OFF 时，MySQL 会对客户端 IP 做反向 DNS 查询，再正向查一次，确保正反解析一致；若失败，就拒绝连接，哪怕你写的 HOST 是 IP 通配符。
- 检查是否真在用 IP 连接：如果客户端用的是域名（如
app-server.internal），而你授权的是'192.168.1.%'，那完全不匹配 - 确认 MySQL 是否做了 DNS 查：执行
SHOW VARIABLES LIKE 'skip_name_resolve';，值为OFF就会查 DNS；设为ON可强制只比对 IP 字符串（推荐生产环境开启） - 防火墙或代理可能修改了源 IP：比如 Nginx 代理没传
X-Real-IP，后端看到的是127.0.0.1，而非真实内网 IP
替代方案：用 user 表直接插入带子网掩码的记录可行吗？
不行。mysql.user 表的 Host 字段仍是字符串类型，没有字段存子网掩码；MySQL 服务层根本不识别 CIDR，所有所谓“子网授权”都得靠应用层或网络层控制。
- 不要手动 INSERT 到
mysql.user并指定Host='192.168.1.0/24'—— 这条记录会被当作字面量，只匹配主机名为该字符串的客户端（几乎不可能） - 不要指望
CREATE USER 'u'@'192.168.1.0/24'能成功，语法直接报错 - 真正可控的边界在：防火墙（iptables/nftables）、云厂商安全组、MySQL Proxy、或前置连接池（如 ProxySQL）做 IP 白名单
实际部署建议：最小权限 + 明确范围 + 验证方式
别把授权粒度押在 HOST 字符串上。一个稳健的组合是：精确 IP 段通配 + 禁用 DNS 解析 + 连接时强制用 IP + 登录后验证 USER() 和 CURRENT_USER()。
- 执行
SET GLOBAL skip_name_resolve = ON;（需重启或动态生效取决于版本），然后FLUSH PRIVILEGES; - 用
GRANT SELECT ON mydb.* TO 'reporter'@'10.0.5.%';，而不是'10.0.%.%'或'%' - 验证是否生效：从目标机器用
mysql -h db-host -u reporter -p连，成功后立即执行SELECT USER(), CURRENT_USER();—— 前者显示你“声称”的用户，后者才是 MySQL 实际匹配到的授权行 - 注意：MySQL 8.0+ 默认认证插件是
caching_sha2_password，老客户端可能连不上，必要时加IDENTIFIED WITH mysql_native_password
IP 段授权表面简单，实际依赖 DNS 行为、网络路径、客户端调用方式三者对齐；漏掉任一环，@'192.168.1.%' 就只是个摆设。
