SHOW GRANTS仅显示USAGE说明用户未被显式授予任何操作权限，仅具备连接能力；常见原因包括用户新建未授权、主机名不匹配或权限作用域错误。
SHOW GRANTS 为什么只显示 USAGE 权限？
执行 SHOW GRANTS 后只看到 GRANT USAGE ON *.* TO 'xxx'@'%' IDENTIFIED BY PASSWORD '*...'，说明该用户确实没被显式授予任何数据库级或表级权限——USAGE 是默认权限，仅表示账户存在且可连接，不包含任何操作能力。
常见原因包括：用户刚创建未授权、GRANT 语句漏写 FLUSH PRIVILEGES（其实 8.0+ 通常不需要）、或用 CREATE USER 单独建号但没跟 GRANT。
- 检查是否真有授权：运行
SELECT * FROM mysql.user WHERE User = 'your_user';，看Select_priv等字段是否为Y - 确认作用域：如果授的是
GRANT SELECT ON test.*，但当前连的是mysql库，SHOW GRANTS仍会显示完整语句，不会因当前库而过滤 - 注意用户名大小写和 host 匹配：
'user'@'localhost'和'user'@'%'是两个不同账号，权限互不影响
查看其他用户的权限要加 FOR 子句
普通用户执行 SHOW GRANTS 只能看到自己权限；要查别人，必须有 SELECT 权限访问 mysql.user 表，或拥有 SELECT 以外的高权限（如 SYSTEM_USER 角色）。
语法是 SHOW GRANTS FOR 'username'@'host'，host 不能省略，哪怕建用户时用了 'user'@'localhost'，这里也得写全。
- 例如查远程用户：
SHOW GRANTS FOR 'api_app'@'192.168.1.%' - 若提示
Access denied，不是语法错，而是当前账号没权限读取其他用户的授权信息 - MySQL 8.0+ 中，角色权限也会体现在结果里，如
GRANT `app_reader`@`%`，需再查mysql.role_edges确认角色所含权限
SHOW GRANTS 输出结果怎么解读？
输出是可直接执行的 SQL 语句形式，但不是“当前生效权限”的实时快照，而是基于 mysql.user、mysql.db、mysql.tables_priv 等系统表拼出来的授权语句。
关键点：权限叠加计算，比如用户有 SELECT 在全局、INSERT 在某库、UPDATE 在某表，则 SHOW GRANTS 会分三行列出对应 GRANT 语句。
-
ON *.*表示全局权限（如SUPER、RELOAD） -
ON `db_name`.*是数据库级，对库内所有表生效 -
ON `db_name`.`table_name`是表级，优先级更高 - 带
WITH GRANT OPTION的行，表示该用户还能把对应权限转授给别人
权限变更后为什么 SHOW GRANTS 没更新？
MySQL 权限缓存在内存中，但绝大多数情况下（8.0.16+）执行 GRANT 或 REVOKE 后自动刷新，无需手动 FLUSH PRIVILEGES。如果改了系统表（如直接 UPDATE mysql.user），才必须执行该命令。
更常见的“没更新”其实是权限作用域理解偏差：比如给 'u'@'127.0.0.1' 授权，但从 localhost 连入，实际匹配的是 'u'@'localhost' 这个账号——这两个 host 在 MySQL 中不等价。
- 确认当前连接使用的账号：
SELECT USER(), CURRENT_USER();，前者是客户端声明的，后者是服务端认证后的实际账号 - 权限检查顺序是：先匹配
User + Host最精确的记录，再逐级回退到通配符，不是简单“取并集” - 如果用代理或连接池，可能复用旧连接，导致新权限在当前会话不生效，需断开重连
权限体系本身不复杂，但 host 匹配逻辑、作用域层级、缓存机制这三点，最容易让人查半天发现只是连错了账号。
