踩坑！真的还有DBA不会进行MySQL用户授权？

一、 案例复现

1. 初始情况

咱们先来还原一下这个经典场景。假设数据库服务器在192.168.56.102上，上面已经存在一个用户，用户名是test，但被严格绑定在了IP地址192.168.56.106上。也就是说，只有从这个特定IP发起的连接，才能用test账号登录。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

从绑定的机器上访问，一切正常，这没问题。

2. 错误授权

问题来了。业务扩张，新增了好几台应用服务器都需要访问这个数据库。为了方便，有人想取消这个IP限制，让test账号能从任何地方登录。于是，一个看似“高效”的操作出现了：

mysql> update mysql.user set host='%' where user='test' and host='192.168.56.106';Query OK, 1 row affected (0.02 sec)Rows matched: 1 Changed: 1 Warnings: 0

命令执行成功，回显也明确提示修改了一行数据。去查mysql.user表，host字段也确实从具体的IP变成了“%”。一切看起来都很完美，对吧？

3. 新节点访问异常

然而，当新增的机器（比如192.168.56.108）尝试连接时，迎头就是一盆冷水：

[root@ob ~]# mysql -utest -p123456 -h 192.168.56.102mysql: [Warning] Using a password on the command line interface can be insecure.ERROR 1045 (28000): Access denied for user 'test'@'192.168.56.108' (using password: YES)

更奇怪的是，原先那台192.168.56.106的机器，访问依然畅通无阻。

4. 刷新权限

这时候，可能有人会拍脑袋想起来：“哦，是不是忘了刷新权限？” 没错，这是一个常见的补救思路。

于是执行FLUSH PRIVILEGES;。

刷新之后，新节点果然能登录了！问题似乎解决了。但别高兴太早，紧接着，新的报错又出现了：登录是能登录了，可一旦执行业务SQL，权限不足的提示又跳了出来。

mysql> select count(*) from db_monitor.db_instances;ERROR 1142 (42000): SELECT command denied to user 'test'@'192.168.56.108' for table 'db_instances'mysql>

5. 新的疑惑

这下彻底懵了。在两个应用节点分别查看权限，得到的结果居然是一样的：都显示没有库级或表级权限。

那么问题来了：为什么一个能执行SQL，另一个却不行？这背后的逻辑到底是什么？

二、权限探索

很多人踩这个坑，根源在于对MySQL权限机制的两个核心特点理解不到位。这可不是简单的“改个配置”那么简单。

1. 权限生效的核心：内存缓存与磁盘表不同步

首先得明白，MySQL在启动时，会把所有授权表（user, db, tables_priv等）的内容一口气加载到内存里。之后的每一次权限校验，查的都是内存里的这份缓存，而不是实时去读磁盘上的表文件。

所以，当你直接用UPDATE语句去改mysql.user表时，你只是在磁盘的数据文件上动了手脚。内存里的那份“权限名单”还是老样子，它依然只认“test@192.168.56.106”这个组合。新IP来敲门，内存缓存说“不认识”，自然就给挡在门外了。

这就好比你改了系统的配置文件，却没重启服务——改动根本没生效。执行FLUSH PRIVILEGES，作用就是让MySQL重新把磁盘上的权限表读到内存里，所以登录问题解决了。但这只是第一步。

2. 权限的本质：(user, host) 二元组决定一切

这才是关键所在。在MySQL眼里，根本不存在一个孤零零的用户“test”。它认的是“用户名+主机”这个不可分割的整体，也就是(user, host)二元组。

‘test’@‘192.168.56.106’ 和 ‘test’@‘%’，这是两个完全独立的用户账户，它们可以拥有不同的密码、不同的权限。你用UPDATE把前者的host改成‘%’，在MySQL的权限体系看来，并不是给老用户扩大了访问范围，而是把老用户‘test’@‘192.168.56.106’的记录，直接替换成了一个全新的用户‘test’@‘%’的记录。如果这个新用户之前不存在，也没有被授予过任何权限，那它可不就是个“空壳账户”吗？能登录（因为user表里有记录），但进去后什么都干不了。

3. 隐藏坑：权限表关联异常

事情还没完。MySQL的权限是分层级存储的：user表管全局权限，db表管数据库权限，tables_priv管表权限，等等。这些表之间，靠的就是(user, host)这个二元组来关联。

你只改了user表的host，但db表里对应的权限记录，关联的host可能还是旧的‘192.168.56.106’。即便执行了FLUSH PRIVILEGES，内存里加载出来的关联关系也是错位的。这就导致了那个诡异的现象：从新IP（192.168.56.108）登录的用户，在检查db表权限时，找不到匹配‘test’@‘%’的记录，所以没有任何库权限。

看看当时的库级权限表就一目了然了：

看见了吗？权限只授予了host为192.168.56.106的记录。这就是为什么只有那台老机器能执行业务SQL，新来的全都被拒之门外。

三、正规授权操作

摸清了病因，开药方就简单了。先说说怎么补救已经搞乱的现场，再讲讲从一开始就该用的标准操作流程。

1. 补救操作

如果已经手快执行了那个UPDATE，并且导致了权限混乱，可以按以下步骤收拾残局：

首先，清理掉那个已经变异的旧账号。直接删除它：

drop user test@'192.168.56.106';

然后，为真正需要的‘test’@‘%’用户重新授予完整的权限。

完成后再查看权限表，关联关系就正确了。

2. 正常操作

那么，正确的“扩权”姿势应该是怎样的呢？核心思想是：创建新用户，而不是修改老用户。即使你想复用原账号的密码和权限，也有标准方法。

先把环境还原到初始状态。

（1）查看原有账号信息

首先，获取原账号的认证信息（比如加密后的密码哈希）。使用命令：

show create user test@'192.168.56.106';

这里有个细节需要注意：对于MySQL 8.0及以上版本，如果使用caching_sha2_password插件，密码哈希值不能直接以字符串形式复制使用，否则会报错。

ERROR 1827 (HY000): The password hash doesn't ha ve the expected format.

解决办法是开启十六进制显示模式，获取十六进制格式的哈希值。

SET print_identified_with_as_hex = 1;

（2）查看授权信息

接着，查看原账号拥有哪些权限，新账号需要照葫芦画瓢授予一遍。

mysql> show grants for test@'192.168.56.106';

（3）授权并查看结果

最后，结合上面两步获取的信息，执行创建用户并授权的语句。注意把主机部分替换成新的（比如‘%’或另一个具体IP）。

授权完成后，务必再次检查确认。

至此，一个权限完整的新账号就创建好了。

3. 原账号的处理

如果新建的账号主机是‘%’（允许所有IP），那么可以考虑删除原账号‘test’@‘192.168.56.106’。如果新建的账号是另一个具体IP（这是更推荐的做法），比如‘test’@‘192.168.56.108’，那么原账号需要保留，并且后续授权时，要确保所有相关的账号都得到了必要的权限。

4. host设为%的风险及注意事项

图省事把host设为‘%’，在测试环境或许可以，但在生产环境，这无异于打开了一扇危险的大门。

（1）安全风险：暴露权限入口

‘%’意味着允许从任何网络可达的IP进行连接。这大大增加了被暴力破解、中间人攻击的风险，甚至可能成为攻击者在内网横向移动的跳板。

最佳实践是：遵循最小权限原则，生产环境尽量使用具体的IP或子网（如‘192.168.56.%’）来限定访问来源，避免使用‘%’。

（2）常见误区：%不匹配localhost

还有一个容易混淆的点：‘%’通配符只匹配TCP/IP连接，不匹配本地Unix socket连接（localhost）。如果你需要用户既能本地登录又能远程登录，必须创建两个独立的用户：‘test’@‘localhost’ 和 ‘test’@‘%’，并分别授权。

四、总结

记住下面这三点，就能从根本上避开这个“权限陷阱”：

第一，理解缓存机制。 直接修改mysql.user等系统表后，必须执行FLUSH PRIVILEGES来刷新内存权限缓存。但更要明白，这只能同步用户身份信息，解决不了关联权限表（如db表）的匹配问题。

第二，牢记二元组原则。 MySQL的权限核心是(user, host)组合。修改host本质是创建了一个新用户，必须为其独立授权。

第三，严守安全底线。 生产环境慎用host=‘%’。优先指定IP或IP段，严格控制访问来源，这是数据库安全的基本要求。

很多MySQL权限问题，都是因为对其底层机制一知半解，凭感觉操作导致的。看似简单的一句UPDATE，背后牵扯的是整个权限体系的运作逻辑。处理权限，还是得按规矩来。