SHOW GRANTS 是最轻量可靠的方式，直接显示当前用户显式授予的权限语句；它不显示角色继承权限，需结合 mysql.role_edges 查询；查他人权限时必须严格匹配 User@Host；无 mysql 库 SELECT 权限时 SHOW GRANTS FOR 会失败；批量审计宜直查 mysql.user 等系统表，并注意 FLUSH PRIVILEGES 刷新缓存。
直接执行 SHOW GRANTS 就能看到当前权限
这是最轻量、最可靠的方式——只要你连得上 MySQL，不需要任何额外权限就能立刻查清自己能干什么。SHOW GRANTS 输出的是真实生效的授权语句，比如 GRANT SELECT, INSERT ON `orders`.* TO 'app'@'%'，一眼就知道能操作哪些库表、有哪些动作权限。
- 命令就是
SHOW GRANTS;，不带参数，不加FOR，敲完回车就出结果 - 等价写法还有
SHOW GRANTS FOR CURRENT_USER;或SHOW GRANTS FOR CURRENT_USER();，效果完全一样 - 注意：它不会显示“通过角色继承来的权限”（MySQL 8.0+ 角色机制下），只展示显式授予的权限。如果用户绑了角色，得额外查
mysql.role_edges
想确认自己到底是哪个用户登录的？用 CURRENT_USER() 不要用 USER()
很多人误以为 USER() 返回的就是当前权限归属账户，其实不是。USER() 显示的是你“怎么连进来的”，比如 'admin'@'192.168.1.100'；而 CURRENT_USER() 才是 MySQL 实际用来鉴权的那个账户，比如 'dev_role'@'%'（如果是通过代理或角色激活登录的）。
- 查权限前先跑一句：
SELECT CURRENT_USER();，确保你查的是系统真正认的这个身份 - 如果输出是
'root'@'localhost'，那SHOW GRANTS查的就是这个账号的权限；如果是'jane'@'%'@'%'这种嵌套格式，说明用了代理用户，权限可能来自上级账户
查别人权限时，@'host' 必须严丝合缝，漏一个字符都报错
执行 SHOW GRANTS FOR 'api_user'@'%'; 却报 ERROR 1141 (42000): There is no such grant defined for user 'api_user' on host '%'？大概率是 host 写错了。MySQL 把 'api_user'@'localhost' 和 'api_user'@'%' 当作两个完全不同的用户。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先查真实注册信息：
SELECT User, Host FROM mysql.user WHERE User = 'api_user'; - 复制结果里的完整
User@Host字符串，粘贴进SHOW GRANTS FOR，别手动改%或加空格 - 没有
SELECT权限在mysql库时，SHOW GRANTS FOR会直接拒绝，不是权限没设好，而是你没资格看别人
需要批量审计或确认某类权限开关状态？绕过 SHOW GRANTS，直查 mysql.user
SHOW GRANTS 输出是 SQL 语句，解析起来麻烦，也不适合脚本判断。比如你想确认所有用户是否都禁用了 DROP，直接读字段更稳。
- 全局权限字段如
Select_priv、Drop_priv、Super_priv值为'Y'或'N'，查mysql.user表即可：SELECT User, Host, Drop_priv FROM mysql.user; - 但注意：这些字段只反映全局权限，数据库级（如
GRANT SELECT ON mydb.*）得查mysql.db，表级得查mysql.tables_priv——漏掉任一表，权限图谱就不全 - 手动 UPDATE 过系统表后，记得
FLUSH PRIVILEGES;，否则缓存不刷新，SHOW GRANTS和实际行为会不一致
角色权限、跨表权限、手动改系统表后的缓存刷新——这几个点不主动查，很容易以为“权限已删”，结果发现还能 DROP 表。
