MySQL用户并不是单独的'user'，而是由'user'@'host'共同组成的完整身份标识；Host匹配遵循最长前缀优先和更精确记录优先的规则，例如192.168.1.105会优先命中'192.168.1.105'，而不是'%'；%只能替代单个段，不支持跨段匹配，也不会自动进行CIDR网段计算；'localhost'与'127.0.0.1'并不等同；CURRENT_USER()返回的是实际命中的账户，USER()只是客户端提交的登录声明。
MySQL用户不是“用户名”，而是'user'@'host'这个完整字符串
很多人以为，执行CREATE USER 'app'就已经创建了一个名为app的MySQL用户，但实际上它等价于'app'@'%'。这是因为在MySQL 5.7及以上版本中，系统会默认把host补全为%。而这个%在Unix socket连接场景下并不会匹配localhost。这意味着，你使用mysql -u app -h 127.0.0.1通常可以正常连接，但如果直接执行mysql -u app（默认通过socket连接），反而可能失败。根本原因是，后者实际要匹配的是'app'@'localhost'，而这条账户记录并不存在。
真正决定权限与登录行为的，是由user和host两个字段组成的联合标识，它们在mysql.user表中构成唯一索引。哪怕只修改其中一个字段，例如把'app'@'192.168.1.100'改成'app'@'192.168.1.%'，本质上也会变成另一条全新的MySQL账户记录，原有权限不会自动继承。
Host字段匹配不是“模糊查找”，而是最长前缀优先的精确比对
MySQL在查找mysql.user表中的账户时，并不是像普通SQL WHERE条件那样简单逐行扫描，而是会优先根据host字段进行“最长前缀匹配”。例如客户端IP为192.168.1.105时，MySQL通常会按以下顺序尝试匹配：
'app'@'192.168.1.105'（完全一致，优先级最高）'app'@'192.168.1.%'（%只能替代一个段，优先级次之）'app'@'%'（范围最宽，优先级最低）
需要特别注意的是：'app'@'192.168.%'并不会匹配192.168.1.105，因为%只能替代一个“段”，不能跨段使用；而'app'@'192.168.1.0/24'即使在MySQL 8.0+中支持用CIDR形式创建，它本质上仍然只是一个完整字符串，实际匹配时依旧按字面值进行比较，而不是按真实子网范围计算。
常见的MySQL用户Host匹配陷阱包括：
'app'@'localhost'与'app'@'127.0.0.1'是两条完全独立的账户记录，彼此不会互相生效'app'@'%.example.com'要求DNS能够正常解析，并且主机名需要字面一致，不能依赖反向DNS自动转换CURRENT_USER()返回的结果才是当前实际命中的MySQL账户，USER()只是客户端声明的登录身份，两者经常并不相同
为什么直接UPDATE mysql.user表大概率出错
手动执行UPDATE mysql.user SET Host='10.244.1.%' WHERE User='app' AND Host='10.244.1.15';看起来很直接，但在MySQL账户管理中往往会埋下问题，至少容易忽略以下三点：
- 如果已经存在优先级更高的记录（例如
'root'@'localhost'），那么它可能会先被匹配，导致你修改后的新记录根本没有机会生效 - 在MySQL 8.0+中，
authentication_string字段依赖具体认证插件（如caching_sha2_password），直接UPDATE可能造成密码字段与认证插件不兼容，进而触发ERROR 2059 - 修改完成后还必须执行
FLUSH PRIVILEGES，否则权限缓存不会刷新，账户变更可能不会立即生效
更安全、也更符合官方建议的做法，是使用DROP USER 'app'@'10.244.1.15';然后再执行CREATE USER 'app'@'10.244.1.%' IDENTIFIED WITH caching_sha2_password BY 'xxx';重新创建账户，这样可以让MySQL自动维护相关字段的一致性，降低账户异常和认证失败的风险。
生产环境该用IP还是%？关键看网络是否确定
使用%虽然省事，但在生产环境中的安全风险很高：一旦应用迁移到公网环境，或者容器网络范围发生变化，就可能等于对所有来源开放数据库入口。更稳妥的MySQL权限配置方式，是根据实际部署拓扑来选择合适的host值：
- Kubernetes Pod使用固定CIDR（如
10.244.0.0/16）→可使用'app'@'10.244.%.%'，或者按网段进一步收紧为'app'@'10.244.1.%' - Docker Compose环境 →建议显式创建
'app'@'host.docker.internal'，不要假设%一定能自动覆盖所有连接来源 - 云服务器内网IP长期稳定 →直接配置为
'app'@'10.0.1.23'，相比通配符更精确、更易于安全控制
还有一个非常容易被忽略的关键点：MySQL的host匹配发生在TCP握手之后、用户认证之前，它不会依赖DNS解析结果，也不会进行真正的网络层校验——只要客户端声明自己来自某个IP或主机名，MySQL就会按照这个字符串去匹配账户表。因此，host字段的本质更接近“身份来源声明的匹配条件”，而不是“真实网络来源的安全验证”。
