mysql中%不匹配localhost，因为认证时按主机名精确度排序，localhost作为字面量主机名优先级高于通配符%，只要存在'user'@'localhost'账户，本地连接就始终匹配它而非'user'@'%'。
MySQL里%和<em></em>不是普通字符，是权限匹配时的通配符——%匹配任意长度字符串，匹配单个任意字符。只要没加反引号或转义，它们就会触发模式匹配，而不是字面量匹配。
host字段里的%为什么有时不生效？
因为%只在mysql.user表的Host字段中起作用，且匹配顺序严格按字典序：MySQL从上到下扫描权限表，遇到第一条匹配就返回结果，不再继续。
-
'app'@'192.168.1.%'和'app'@'%'同时存在时，如果'app'@'%'在表里排在前面，那192.168.1.100也会走这条规则，哪怕你本意是限制子网 -
'app'@'localhost'永远比'app'@'%'优先——这不是bug，是设计：localhost走socket连接，MySQL把它当作最高优先级的host值 - 用
SELECT User, Host FROM mysql.user ORDER BY Host;能看清实际匹配顺序，别只靠SHOW GRANTS
为什么'app'@'web1'突然连不上了？
MySQL默认会对客户端IP做反向DNS解析（gethostbyaddr()），把192.168.1.100查成web1.internal，然后拿这个解析结果去匹配Host字段。如果表里只写了'app'@'web1'，但解析出来是web1.internal，就不匹配。
-
CURRENT_USER()返回的是匹配成功的user@host，USER()返回的是连接时声明的用户名和客户端IP/主机名；两者不一致基本就是DNS解析惹的祸 - 临时验证方法：
mysql -h ::1 -u app -p（IPv6回环绕过IPv4 DNS）或sudo systemctl stop systemd-resolved停本地DNS服务 - 根治必须加
skip-name-resolve = ON到[mysqld]段并重启，否则所有客户端改host都没用
如何避免_被当成通配符？
数据库名、表名含下划线时，授权语句里不加反引号+双重转义，db_1会匹配db01、dba1、db 1等30+个库——这不是误配置，是MySQL解析器严格执行LIKE语义。
- 正确写法只有：
GRANT SELECT ON `db_1`.* TO 'u'@'h';（注意：反引号`和反斜杠缺一不可） - Shell脚本或Ansible里要写成
db\_1：Shell先吃掉一层，MySQL才能收到真正的_ - 更稳妥的做法是绕过通配符：MySQL 8.0+用角色，
CREATE ROLE 'reader'; GRANT SELECT ON `db_1`.* TO 'reader'; GRANT 'reader' TO 'app_user'@'10.20.%';
为什么FLUSH PRIVILEGES有时没用？
它只刷新内存中的权限缓存，但前提是——你改的是mysql系统表。如果用GRANT或REVOKE命令修改权限，MySQL会自动同步到内存，FLUSH PRIVILEGES纯属多余；只有直接UPDATE mysql.user后才需要它。
- 执行
FLUSH PRIVILEGES前，先确认你改的是哪张表：SELECT * FROM mysql.user WHERE User='u' AND Host='h'; - 如果
SHOW GRANTS FOR 'u'@'h'输出和你预期不符，大概率是GRANT语句本身没生效（比如host拼错、没加反引号、_没转义） - 别在
GRANT后机械执行FLUSH PRIVILEGES，这反而会掩盖真实问题
真正麻烦的不是语法记不住，而是权限匹配发生在多个层面（user→db→tablespriv）、多条记录之间有隐式优先级、且DNS解析和通配符行为会叠加影响。一个少转一次义，或一条Host记录位置放错，都可能让权限在生产环境悄悄越界。
