mysql权限匹配不是模糊查找而是精确比对，因为host字段仅支持字面匹配或单段%通配（如'192.168.1.%'），不支持正则、cidr或dns反查；匹配按“最具体host优先”排序，且current_user()返回值必须与mysql.user表中user+host完全一致才生效。
MySQL权限匹配为什么不是“模糊查找”而是“精确比对”？
因为 mysql.user 表的 Host 字段只做字面匹配或前缀通配（如 '192.168.1.%'），不支持正则、CIDR 或 DNS 反查。哪怕客户端真实 IP 是 192.168.1.105，你写成 '192.168.1.0/24' 或 '192.168.%' 都会失败——MySQL 不解析子网，只认点分十进制 + 单个 % 段。
常见错觉：'app'@'%' 能覆盖所有情况？其实它不匹配 localhost（Unix socket 场景），也不高于 'app'@'127.0.0.1' 的优先级。MySQL 匹配顺序是：**最具体的 Host 先命中**，比如：
-
'app'@'192.168.1.105'>'app'@'192.168.1.%'>'app'@'%' -
'app'@'localhost'和'app'@'127.0.0.1'完全独立，互不影响 -
'app'@'host.docker.internal'必须字面存在，不能靠 DNS 解析自动转成 IP
为什么 SELECT USER(), CURRENT_USER() 是排查起点？
很多人以为自己连的是 'app'@'192.168.1.5'，结果 CURRENT_USER() 返回的是 'app'@'localhost' ——说明 MySQL 实际走的是本地 socket，不是 TCP。这直接导致你给 'app'@'192.168.1.5' 授的权限完全没生效。
关键区别：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
USER()：客户端声称的身份（可能被 DNS 或连接参数误导） -
CURRENT_USER()：MySQL 真正用来查mysql.user表的键值，必须和表中某行User+Host完全一致 - 两者不一致，就说明 Host 匹配失败，别急着改密码或加权限
直接 UPDATE mysql.user 为什么大概率踩坑？
手动更新 Host 字段看似简单，但忽略三点：
- 已有更高优先级记录（如
'root'@'localhost'）会拦截后续匹配，'root'@'%'根本没机会生效 - 没同步更新
authentication_string或plugin字段，MySQL 8.0+ 可能报ERROR 2059 - 忘记执行
FLUSH PRIVILEGES，缓存未刷新，改了也白改
更稳妥的做法是用 GRANT 或 DROP USER + CREATE USER 重建，让 MySQL 自动维护字段一致性。
生产环境 Host 值该用 IP 还是 %？
取决于网络确定性：
- 固定 IP（如 K8s Pod CIDR 或云服务器内网 IP）→ 用
'app'@'10.244.1.15'或'app'@'10.244.1.%' - Docker Compose / host.docker.internal → 显式创建
'app'@'host.docker.internal'，别指望 % 自动覆盖 - 绝对避免
'app'@'*.local'或'app'@'myserver'—— DNS 故障时权限立即失效
真正容易被忽略的点：MySQL 的 Host 匹配发生在 TCP 握手后、认证前，它看到的是客户端发起连接时操作系统报告的源地址（或 DNS 解析结果），不是你在连接字符串里写的 host 名。所以容器里填 host.docker.internal，MySQL 就真拿这个字符串去查表 —— 不是查它解析出来的 IP。
