直接执行SHOW GRANTS即可查看当前用户权限，它默认作用于CURRENT_USER()匹配的真实'user'@'host'，输出中GRANT后的权限列表、ON后的作用范围、TO后的用户标识三部分最关键；不可靠的是直接查mysql.user表，因其仅存部分全局权限且忽略库表级及角色权限。
直接执行 SHOW GRANTS 就行，不用加参数
只要已成功连接 MySQL（比如 mysql -u appuser -p 进去），在命令行里敲 SHOW GRANTS; 就能立刻看到当前会话用户实际生效的全部权限语句。它自动作用于 CURRENT_USER()，不是你登录时写的那个账号名，而是 MySQL 权限系统最终匹配到的真实 'user'@'host'。
常见误区：
- 写成
SHOW GRANTS FOR USER();—— 错，USER()是登录声明身份，可能和实际权限归属不一致 - 漏掉分号或写成
show grants（小写）—— 虽然 MySQL 不区分大小写，但习惯大写更稳妥，且必须加分号 - 以为要先
USE mysql;才能执行 —— 不需要，SHOW GRANTS不依赖任何数据库上下文
SHOW GRANTS 输出里哪些部分最关键
结果是一条或多条 GRANT ... ON ... TO ... 语句，重点盯三块：
-
GRANT后面的权限列表：比如SELECT, INSERT或ALL PRIVILEGES，注意USAGE表示“仅能连接”，不是 bug -
ON后面的作用范围：*.*是全局，`db1`.*是库级，`db1`.`tbl`是表级，反引号不能少 -
TO后面的用户标识：'appuser'@'10.20.%'，单引号是语法必需，host 部分含通配符也要原样保留
如果输出里有 WITH GRANT OPTION，说明这个用户能把权限再授给别人——生产环境要重点审计。
为什么不能直接 SELECT * FROM mysql.user
MySQL 8.0+ 中，mysql.user 表只存极少数全局权限字段（如 Select_priv），而 EXECUTE、CREATE VIEW 等已移入数据字典；它完全不包含库级（mysql.db）、表级（mysql.tables_priv）、列级权限，也看不到角色继承的权限。查这张表只会严重漏权，尤其对启用角色的用户几乎无效。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
更麻烦的是：mysql.user 里的 Y/N 字符串还得人工映射到具体操作，不如 SHOW GRANTS 输出的 SQL 语句所见即所得。
看到 GRANT USAGE ON *.* TO ... 就代表没权限？
不一定。这仅表示该用户没有全局权限，但它完全可能拥有库级或表级权限。比如被授予了 SELECT ON `orders`.*，mysql.user 里对应字段仍是 N，但 SHOW GRANTS 会明确列出那条语句。
所以别急着下结论——只要输出里还有别的 GRANT 行，就说明有真实可用权限。真正要警惕的是：整段输出只有 USAGE 一条，且试 USE db_name; 或 SELECT 1; 都失败。
最易被忽略的一点：权限是按 CURRENT_USER() 匹配的，不是你登录时用的账号字符串。连上去第一件事，先执行 SELECT CURRENT_USER(); 确认到底是谁在干活。
