mysql用户匹配按host字段“越具体越优先”排序：精确ip（如192.168.1.100）>网段通配（如192.168.1.%）>主机名>‘%’；‘%’不匹配localhost，因socket连接强制识别为localhost；真实排序由源码sort_hosts()实现，可用order by length(host) desc, host desc近似模拟。
MySQL用户匹配规则：host字段的排序逻辑是什么
MySQL在认证时不是逐条扫描user表，而是按host字段的确定性从高到低排序匹配。具体顺序是：
- 完全匹配IP（如
'192.168.1.100'） - 网段通配（如
'192.168.1.%'） - 主机名（如
'app-server.local'） - 通配符
'%'（但注意：'%'不匹配localhost，这是个常见误区）
关键点：MySQL内部把所有host值转换为排序键，其中越“具体”的host排越前。例如'10.0.0.5'一定优先于'10.0.0.%'，哪怕后者在mysql.user表里物理位置更靠上。
如何查看当前生效的用户匹配路径
直接查mysql.user表无法反映真实匹配顺序，必须用排序查询模拟MySQL内部行为：
SELECT User, Host,
CASE
WHEN Host = '%' THEN 100
WHEN Host LIKE '%_%' OR Host LIKE '%.%' THEN 50
WHEN Host REGEXP '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$' THEN 0
ELSE 30
END AS sort_weight
FROM mysql.user
WHERE User = 'myuser'
ORDER BY sort_weight ASC, Host DESC;
这个查询只是近似排序——真正逻辑由MySQL C源码中的sort_hosts()函数实现，但上述权重已覆盖95%的生产场景。注意Host DESC是因为MySQL对相同权重的host按字典逆序排（'192.168.1.99' > '192.168.1.100'），这点常被忽略。
常见权限冲突现象及验证方法
遇到“明明授权了却连不上”或“连上了但权限不对”，大概率是匹配到了意外的用户记录。典型现象包括：
- 用
mysql -u myuser -h 192.168.1.50连接，实际匹配到myuser@'192.168.%'而非myuser@'192.168.1.50' - 本地用
mysql -u myuser -h 127.0.0.1连，却触发myuser@'%'而非myuser@'localhost'（因为localhost只对socket连接生效） - DNS反向解析开启时，
myuser@'web01.example.com'可能被匹配，即使你输的是IP
验证方式：
- 在目标客户端执行
SELECT USER(), CURRENT_USER();，前者是“你声称的身份”，后者是“MySQL实际认证的身份” - 检查
SHOW GRANTS FOR CURRENT_USER();，确认看到的是哪条记录的权限 - 临时关闭DNS解析（启动mysqld时加
--skip-name-resolve）排除主机名匹配干扰
修改host匹配行为的实操边界
不能强行改变MySQL的排序逻辑，但可通过以下方式控制匹配结果：
- 删除冗余记录：
DELETE FROM mysql.user WHERE User='myuser' AND Host IN ('%', '192.168.%') AND ...，保留最精确的一条 - 使用
CREATE USER显式指定host，避免依赖GRANT自动创建（GRANT在用户不存在时会创建Host='%'的兜底记录） - 对于需要多网段访问的用户，用多个精确host代替宽泛通配：
myuser@'10.0.1.0/24'（MySQL 8.0+支持CIDR语法）比myuser@'10.0.1.%'更安全 - 注意
FLUSH PRIVILEGES必须执行，否则mysql.user表变更不生效
真正棘手的是混合使用IP、域名、通配符且DNS不稳定的情况——这时CURRENT_USER()返回的结果可能每次都不一样，必须统一用IP或禁用DNS解析。
