MySQL权限含义以官方文档《Privileges Provided by MySQL》表格为准，明确列出各权限的适用层级、对应操作、隐式权限及依赖条件；SHOW GRANTS仅显示显式授予语句，不揭示隐含行为或作用域细节。
查 MySQL 权限含义，别翻博客，直接看官方权限矩阵
MySQL 官方文档里有一张完整的 Privileges Provided by MySQL 表格，它按权限名逐条说明：适用层级（全局 / 库 / 表 / 列）、对应操作、是否包含隐式权限、是否需额外权限配合。这不是“SELECT 就是查数据”这种模糊描述，而是明确写清“SELECT 在表级授予时允许 SELECT ... FROM db.tbl，但在数据库级授予时还隐含允许 SHOW CREATE TABLE”。
为什么 SHOW GRANTS 看不到完整语义？
SHOW GRANTS FOR 'u'@'h' 只返回当前用户被显式授予的权限语句，不展开解释、不提示隐含行为、不标注作用域冲突。例如：
- 你看到
GRANT SELECT ON sales.* TO 'u'@'h'，但不知道它其实也允许SHOW VIEW（只要视图在sales库内） - 你看到
GRANT INSERT ON *.* TO 'u'@'h'，但没意识到这会绕过sql_mode=STRICT_TRANS_TABLES对某些插入的约束（因全局 INSERT 权限可执行INSERT INTO mysql.user类操作） - 你授了
CREATE ROUTINE，却没注意它必须和ALTER ROUTINE配合才能修改已有存储过程——单独授前者，用户只能新建，不能改
重点权限的常见误读与实际影响
几个高频权限点，官方文档定义和实操差异明显：
-
PROCESS：不是“看自己正在跑什么 SQL”，而是能SHOW PROCESSLIST查所有连接，包括 root 的；在 8.0+ 还默认禁止非 super 用户查看系统线程（需额外SYSTEM_VARIABLES_ADMIN） -
RELOAD：不只是FLUSH LOGS，还包括FLUSH PRIVILEGES（但 5.7+ 后 GRANT 自动重载，这权限已基本无用），更关键的是它允许FLUSH TABLES WITH READ LOCK—— 这会阻塞所有写入，生产环境误用等于人工停服 -
GRANT OPTION：不是“能给别人授权”，而是能将自己**已拥有的同级或更低权限**转授出去；若你只有SELECTonsales.*，就无法用它授予别人UPDATE或sales2.*
权限查证必须结合两步：文档 + 实际校验
官方权限矩阵告诉你“理论上能做什么”，但 MySQL 运行时是否真放行，取决于三层叠加结果：
- 用户是否通过第一阶段认证（
user@host匹配mysql.user.Host） - 请求对象是否落在任一有效权限的作用域内（比如
SELECT FROM app.users，需匹配app.*或app.users或*.*中至少一条） - 该操作是否被显式拒绝（
DENY仅 8.0.16+ 支持，且优先级高于 GRANT）
所以遇到 Access denied for user，先查 SHOW GRANTS，再对照 官方权限矩阵 确认语义，最后用 SELECT * FROM mysql.db WHERE User='u' AND Host='h' AND Db='target_db' 检查底层记录是否存在——缺哪一层，都可能让权限“看起来有，实际没效”。
