踩坑！真的还有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，背后牵扯的是整个权限体系的运作逻辑。处理权限，还是得按规矩来。
相关攻略
MySQL排序查询性能优化指南：深入解析执行计划与索引顺序调整策略 MySQL排序查询变慢的核心原因：为什么ORDER BY会导致性能骤降？ 许多开发者在MySQL数据库优化中常遇到一个典型问题：不带排序的查询执行迅速，一旦添加ORDER BY子句，响应时间便急剧增加。这种现象的根本原因在于MySQ
EXPLAIN 结果中 key 字段为空，是否意味着索引失效？ 先别急于下定论。当 EXPLAIN 输出的 key 列显示为 NULL 时，许多开发者会直接认为“索引没有生效”。实际上，这仅表明 MySQL 查询优化器在最终的执行计划中，未选择使用任何索引来检索数据。其背后的原因，往往比表面现象更为
探讨InnoDB的“关机策略选择器”：innodb_fast_shutdown 在MySQL的日常运维中，你是否遇到过这些令人头疼的场景？服务器关闭流程耗时十几分钟，紧急重启却迟迟无法完成；或是数据库异常宕机后，启动过程异常缓慢，日志里塞满了恢复信息；又或者，在升级MySQL版本后，数据文件竟出现了
MySQL中IS NULL查询能否利用索引，取决于索引类型、字段是否允许NULL、MySQL版本及存储引擎；在InnoDB中，NULL值不参与B+树排序，当NULL值比例较高时，优化器可能放弃使用索引。自MySQL 5 7版本后，对IS NULL查询的索引支持有所增强，但联合索引中若最左前缀列为NU
MySQL乐观锁实战指南：高并发场景下如何高效替代SELECT FOR UPDATE 首先明确一个核心的技术结论： 乐观锁因其无需加行级锁、可规避锁等待与死锁的特性，在读多写少、冲突概率较低的业务场景（例如用户积分变动、状态轻量更新）中，能够显著提升系统吞吐量。其核心机制是通过UPDATE语
热门专题
热门推荐
三季报收官，光伏企业交出了近年难得的尚佳成绩 三季报发布完毕，光伏行业总算交出了一份近年来难得的、还算不错的成绩单。市场等这一刻，确实等了挺久。 根据Choice光伏设备板块收录的78家企业财报，整个板块三季度的净利润达到了7 58亿元。这个数字怎么看？不妨对比一下：就在二季度，板块的净亏损还高达4
北京天兵科技天龙三号火箭首飞失利解析 最近，北京天兵科技自主研发的天龙三号大型液体运载火箭，在酒泉卫星发射中心执行首次飞行任务时遭遇失利，这无疑是给国内商业航天关注者带来了一次震动。这款被寄予厚望的火箭，瞄准的是近地轨道20吨级的可回收运力，其设计初衷是通过低成本、高频次的发射模式，抢占一箭36星组
苹果芯片实战：48台Mac mini搭建本地AI集群，如何碘伏云端语音识别？ 最近科技圈有个挺有意思的消息。知名播客应用Overcast的开发者Marco Arment，自己动手搭了个“大家伙”——一个由48台苹果Mac mini组成的服务器集群。关键是，这个集群没走寻常路，它完全绕开了云端AI服务
纯电赛道再进化：领克10系列如何重新定义“运动轿车”？ 如果问，纯电时代最让人怀念传统燃油车的是什么？很多人会把票投给两件事：说走就走的补能，和随心所欲的操控。最近，领克用一场全球首秀给出了自己的答案。旗下全新的中大型运动轿车领克10，以及更极致的性能版本领克10+联袂登场。这不仅仅是两款新车，更像
苹果正酝酿一款“可自定义”的Vision Pro，核心框架支持模块化拼装 一则来自供应链和专利领域的消息，引起了科技圈的关注。4月8日，有外媒报道指出，苹果似乎并不满足于当前的一体化设计思路，其正在深入探索如何打造一款高度可自定义的Apple Vision Pro。未来的VR AR头显，用户或许能像