先执行select user(), current_user()确认实际认证账号，再用show grants for current_user()查真实权限；若两者不一致，说明mysql按host匹配选中了权限更小的同名用户，show grants仅反映current_user()对应记录的权限。
SELECT USER() 和 CURRENT_USER() 不一致导致权限错判
你看到的权限不是“你认为自己是谁”的权限，而是 MySQL 实际认证成功的那个账号的权限。执行 SELECT USER(), CURRENT_USER();，如果两者不同（比如 USER() 返回 'app'@'127.0.0.1'，而 CURRENT_USER() 返回 'app'@'localhost'），说明 MySQL 按 host 匹配规则选中了另一个同名用户——它权限更小，甚至可能只有 USAGE（仅能登录，不能做任何事）。SHOW GRANTS 永远只查 CURRENT_USER() 对应的记录，不会管你输的是谁。
多个同名用户共存时，SHOW GRANTS 只显示第一条匹配记录
MySQL 允许存在 'u'@'10.20.1.%' 和 'u'@'%' 两个账号，但 SHOW GRANTS FOR 'u'@'%' 只会返回 mysql.user 表里顺序靠前的那条，未必是你当前连接实际生效的那条。真正起作用的是“最具体 host 匹配”：从 'u'@'10.20.1.5' 连入，即使 'u'@'%' 权限更大，MySQL 也会优先用 'u'@'10.20.1.%' 的权限。验证方式是：SELECT Host, User FROM mysql.user WHERE User = 'u';，再逐个查 SHOW GRANTS FOR 'u'@'host'。
角色权限不被 SHOW GRANTS 默认展开
MySQL 8.0+ 引入角色后，SHOW GRANTS 默认只列出直接授予的权限和当前激活的角色名，不会把角色内部的权限也列出来。例如你执行了 CREATE ROLE 'ro_role'; GRANT SELECT ON db.* TO 'ro_role'; GRANT 'ro_role' TO 'u'@'%';，SHOW GRANTS FOR 'u'@'%' 只会显示 GRANT ro_role TO 'u'@'%'，但不会告诉你这个角色其实有 SELECT。要查最终生效权限，得结合系统表：SELECT * FROM role_edges WHERE TO_HOST = '%' AND TO_USER = 'u';，再查对应角色的权限。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
表级或列级显式拒绝（DENY）覆盖更高层授权
MySQL 8.0.16+ 支持 DENY 语法，比如你给用户全局 SELECT，又在某张表上加了 DENY SELECT ON db.t1，那对该表的操作就会被拒绝——而 SHOW GRANTS 里根本不会显示 DENY 条目，它只列 GRANT。这种“看不见的拒绝”最容易让人困惑。排查时得查系统表：SELECT * FROM mysql.role_edges WHERE TO_USER = 'u' AND TO_HOST = '%'; 和 SELECT * FROM mysql.tables_priv WHERE User = 'u' AND Table_name = 't1';。
最常被忽略的一点：你看到的 SHOW GRANTS 输出，只是权限快照，不是实时行为日志。它不反映 SQL mode、secure_file_priv 限制、DEFINER 执行上下文，也不体现存储过程里用到的其他用户的权限。权限是否真能用，必须在目标库、目标表、目标连接方式下实测一次 SELECT 1 或 INSERT。
