SHOW GRANTS FOR 是最准确的权限查看方式，它自动聚合全局、库、表、列等所有层级显式授权并以SQL格式输出；单查 mysql.user 表仅得全局权限，会遗漏绝大部分细节。
直接查 mysql.user 表只能看到全局权限，不全
很多用户执行 SELECT * FROM mysql.user WHERE User='xxx'; 后以为权限都在这儿了，其实不是。MySQL 的权限分四层：全局（mysql.user）、库级（mysql.db）、表级（mysql.tables_priv）、列级（mysql.columns_priv），还有存储过程、代理用户等额外权限。单查 user 表漏掉绝大部分细节，尤其当用户只被授了某个库或某张表的权限时，这里会显示 Y/N 但不体现具体对象。
用 SHOW GRANTS FOR 是最准也最省事的方式
SHOW GRANTS FOR 是 MySQL 官方推荐的权限查看方法，它会自动聚合所有层级的显式授权，并按 SQL 语句格式输出，可读性强、无遗漏。注意必须指定主机名，哪怕用户是 'user'@'%'，也不能省略 @ 部分。
实操建议：
- 先确认用户名和主机名是否准确，可用
SELECT User, Host FROM mysql.user WHERE User LIKE '%xxx%';模糊查 - 执行
SHOW GRANTS FOR 'username'@'host';，例如SHOW GRANTS FOR 'app_user'@'10.20.%'; - 如果提示
Access denied，说明当前登录用户没权限查他人权限，需用root或有SELECT权限的管理员账号执行 - 结果中出现
GRANT USAGE ON *.*表示该用户仅创建了账号但未授任何实际权限
权限视图 information_schema.role_table_grants 不适用于普通用户
MySQL 8.0+ 引入了角色机制，information_schema.role_table_grants 只记录角色授予的权限，不是用户直接受权的快照。普通用户即使被赋予了角色，这个视图也不会列出其最终合并后的全部权限——它不递归解析角色继承链，也不包含用户自身的直接授权。所以别指望靠它替代 SHOW GRANTS。
容易踩的坑：
- 误把
role_table_grants当成“用户全部权限总览”，结果漏掉大量内容 - 在 MySQL 5.7 及更早版本中该视图根本不存在，查了会报错
Unknown table - 即使版本支持，也要配合
role_routine_grants、role_column_grants等多个视图才能拼凑出角色权限，远不如SHOW GRANTS一步到位
导出权限做备份或迁移时，别手动拼 SQL
有人想把权限导成 SQL 语句用于恢复，就去 mysql.user 表里手工拼 GRANT，这是高危操作。原因包括：password_expired、account_locked、max_questions 这类属性不会出现在 GRANT 语句里，但影响账号行为；加密方式（如 caching_sha2_password）变更后，旧密码哈希可能失效；不同 MySQL 版本对权限关键字的支持也有差异（比如 BACKUP_ADMIN 在 8.0 才引入）。
稳妥做法是：
- 用
mysqldump --no-data --skip-triggers --compact mysql user db tables_priv columns_priv procs_priv proxies_priv > grants.sql备份权限元数据表（注意加--skip-triggers避免导出触发器） - 若需纯
GRANT语句，仍应以SHOW GRANTS输出为准，再用脚本清洗（比如去掉IDENTIFIED WITH ...部分以防迁移时冲突） - 跨版本迁移前务必检查目标 MySQL 的权限模型变更日志，例如 8.0 移除了
FILE权限的全局控制逻辑
权限不是静态快照，而是运行时聚合结果。SHOW GRANTS FOR 虽然简单，但它背后触发的是实时权限树遍历。如果你发现结果和预期不符，优先怀疑是否刚执行过 FLUSH PRIVILEGES —— 某些授权变更（比如改了 mysql.user 表）需要刷新才生效，而 GRANT 语句本身会自动刷新，这点常被忽略。
