MySQL权限表解析：从mysql.user字段到8.0的角色模型
在MySQL的世界里，权限管理是数据库安全的核心。但你是否遇到过这样的困惑：明明在mysql.user表里看到了权限字段，却搞不清它们具体管什么？或者升级到MySQL 8.0后，发现查出来的权限全是“N”？
其实，这背后是MySQL权限体系的一次重要演进。简单来说，MySQL 5.7及之前版本中，mysql.user表的权限列均为_priv结尾的布尔字段（如Select_priv、Super_priv等），每个字段对应一种全局权限；而到了MySQL 8.0+，这些字段已废弃且恒为‘N’，实际权限由角色和mysql.global_grants等新机制管理。
mysql.user 表里哪些字段是权限列
要搞清楚这个问题，首先得看你的MySQL版本。版本不同，答案截然不同。
在MySQL 5.7及更早的版本中，mysql.user表确实是权限的“大本营”。权限以一个个独立的布尔字段形式存在，比如Select_priv、Insert_priv，每个字段都对应一种全局级别的权限。想知道某个用户能干什么，直接看这些字段是‘Y’还是‘N’就行。
但到了MySQL 8.0，情况就变了。权限管理的核心变成了“角色”。虽然mysql.user表为了兼容性还保留着（比如Account_locked、password_expired这些账户状态字段），但绝大多数真正的权限字段已经被移出了这张表。所以，如果你还在8.0里盯着mysql.user找权限，那基本是白费功夫。
总结一下，查“每一列代表什么权限”，第一步永远是确认版本：
- MySQL 5.7 或更早：直接看
mysql.user字段，权限字段名基本是*_priv形式。 - MySQL 8.0+：
mysql.user中的*_priv字段已废弃（值恒为N），真实权限在mysql.role_edges、mysql.default_roles和INFORMATION_SCHEMA.APPLICABLE_ROLES等处管理。
MySQL 5.7 查看 user 表权限字段含义的实操方法
对于还在使用5.7版本的朋友，最权威的方式当然是查阅官方文档。但如果是在生产环境需要快速确认，有个更直接的办法：
DESCRIBE mysql.user;
执行这条命令，你会看到表结构。这时，重点关注那些字段名里带_priv的列。它们就是权限字段。比如：
Select_priv：决定用户能否在全局级别执行SELECT查询。Super_priv：这可是个“大杀器”。拥有它，就能执行KILL进程、SET GLOBAL修改全局变量，甚至干预其他用户的会话。Grant_priv：注意，这个权限很特别。它只代表用户能给别人授权，并不等于他自己就拥有对应的操作权限。Repl_sla ve_priv：这是给复制从库用的，允许它连接主库执行CHANGE MASTER TO命令。Execute_priv：允许用户执行存储过程。但要注意，这里指的是执行已存在的存储过程，而不是创建或修改它们。
这里有个常见的误区：别把资源限制字段（如max_questions、max_updates）和认证字段（如ssl_type、plugin）当成权限。它们控制的是“能用多少”和“怎么登录”，而不是“能干什么”。
MySQL 8.0+ 为什么 SELECT * FROM mysql.user 看不到有效权限
很多从5.7升级到8.0的DBA都会大吃一惊：为什么查mysql.user，所有*_priv字段都是‘N’？是数据坏了吗？
当然不是。这正是MySQL 8.0权限体系重构的结果。为了更灵活、更安全的权限管理，MySQL引入了基于角色的模型。于是，mysql.user表里的那些老权限字段就被“架空了”——它们变成只读，并且默认值全是‘N’。真正的权限，已经转移到了新的阵地：
- 用户和角色的从属关系，记录在
mysql.role_edges表里。 - 角色具体拥有哪些权限，则分散在
mysql.role_tables_priv、mysql.role_columns_priv等专用表中。 - 全局级别的权限，在MySQL 8.0.16版本之后，统一存放在
mysql.global_grants表里。
所以，在8.0+的环境下，想查看用户权限，最正确、最高效的命令是：
SHOW GRANTS FOR 'username'@'host';
别再执着于直接查询mysql.user了。它现在已经退居二线，主要用来存储账户的元信息，比如密码哈希、账户是否被锁定、密码是否过期等。
容易被忽略的关键点
无论是5.7还是8.0，有一个核心原则始终没变：MySQL的权限检查是分层级的。这意味着，你不能只盯着mysql.user这一张表。
MySQL在判断一个用户能否执行某个操作时，会像漏斗一样逐层过滤：
- 先查
mysql.user（全局权限）。 - 如果不通过，再查
mysql.db（数据库级别权限）。 - 如果还不通过，继续查
mysql.tables_priv（表级别权限）。 - 最后可能还会细化到列级别或存储过程级别。
这就导致了一种情况：哪怕用户在mysql.user表里拥有全局的Select_priv = 'Y'，但如果mysql.db表里对某个特定数据库的Select_priv是‘N’，那么他对这个库依然没有查询权限。
因此，最可靠、最贴近实际权限生效情况的方法，永远是使用SHOW GRANTS命令。它展示的是经过所有层级计算、合并、并处理了拒绝（DENY）规则之后的最终结果。
给你的建议是：下次排查权限问题，别一头扎进表结构里。先SHOW GRANTS FOR CURRENT_USER();看看最终效果，如果有疑问，再根据结果去相应的权限表里溯源。这样效率更高，也更不容易出错。
