SHOW GRANTS FOR 'user'@'host' 仅显示显式授予的权限，不包含角色继承、未激活角色或列级权限（8.0.19前），需用USING子句展开角色权限，且权限匹配以CURRENT_USER()为准。
直接执行 SHOW GRANTS FOR 'user'@'host' 只能看显式权限
这条命令输出的是该用户在 mysql.user、mysql.db、mysql.tables_priv 等系统表中被直接 GRANT 的语句，但它不展开角色继承、不处理未激活角色、也不包含列级权限（MySQL 8.0.19 之前完全不显示）。常见错误是以为结果为空就代表没权限——其实只是没显式授过权。
- 如果用户绑了角色但没设默认角色，或当前会话没执行
SET ROLE，SHOW GRANTS FOR仍只显示空壳 -
mysql.tables_priv.Table_name字段是 base64 编码的，但SHOW GRANTS会自动解码，所以你看不到原始编码值，也别指望从输出反推表名是否含特殊字符 - 执行者必须有访问
mysql.user表的SELECT权限；普通用户查别人权限会报ERROR 1045 (28000)
查角色绑定和叠加权限得用 USING 显式指定
角色权限不会自动“合并”进 SHOW GRANTS FOR 输出，必须靠 USING 子句强制展开。例如用户 'alice'@'%' 被授予了角色 'app_writer' 和 'readonly_analyst'，你要看叠加效果就得写：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
SHOW GRANTS FOR 'alice'@'%' USING 'app_writer', 'readonly_analyst';
-
USING不检查角色是否已激活，它只做静态权限映射——哪怕你没执行过SET ROLE，也能看到理论权限 - 如果
USING后的角色名拼错，或用户根本没被GRANT过该角色，会报ER_ROLE_NOT_GRANTED - 要确认角色是否真在当前会话生效，得查
INFORMATION_SCHEMA.APPLICABLE_ROLES；为空说明没激活，不是没绑定
列级权限和跨层级汇总必须手动联查系统表
MySQL 8.0.19+ 才把列级权限纳入 SHOW GRANTS 输出，此前只能查 mysql.columns_priv 表。而完整权限视图需要拼接多张表，因为权限按优先级逐层覆盖：user > db > tables_priv > columns_priv。
-
mysql.user只存极少数全局权限字段（如Select_priv），多数已在数据字典中移除 -
mysql.db存库级权限，但User和Host必须完全匹配才生效 -
mysql.role_edges是角色关系唯一权威来源，FROM_USER是角色名，TO_USER是被授角色的用户 - 不能用
PREPARE + EXECUTE批量跑SHOW GRANTS FOR，该语句不支持变量绑定
最易被忽略的一点：权限归属以 CURRENT_USER() 为准，不是你登录时写的账号
你用 mysql -u appuser -p 登录，MySQL 实际匹配的是 CURRENT_USER() 返回的 'appuser'@'10.20.30.%' 或类似 host 模式。这个匹配过程受 mysql.user 表中 User/Host 组合、DNS 解析、proxy 用户等影响，和 USER() 返回的登录声明身份可能不一致。
- 执行
SHOW GRANTS时不加FOR就默认作用于CURRENT_USER()，不是USER() - 写成
SHOW GRANTS FOR USER()是错的，会导致查到错误的权限上下文 - 如果你不确定当前匹配的是谁，先执行
SELECT CURRENT_USER(), USER();对比一下
