MySQL权限存储于mysql系统库的五张InnoDB表：user（全局）、db（库级）、tables_priv（表级）、columns_priv（列级）、procs_priv（过程级），修改后需FLUSH PRIVILEGES或重连才生效，且权限检查按user→db→tables_priv→columns_priv→procs_priv短路匹配。
权限不是配置文件，而是五张系统表
MySQL 的所有权限信息都实实在在存放在 mysql 系统库的五张表里：不靠配置文件，不靠内存变量，也不靠临时缓存——改了表就得刷，否则永远不生效。这五张表按权限粒度从粗到细排列：mysql.user（全局）、mysql.db（库级）、mysql.tables_priv（表级）、mysql.columns_priv（列级）、mysql.procs_priv（存储过程/函数级）。它们全都是 InnoDB 引擎（MySQL 8.0+），支持事务，但 MySQL 启动时会把它们全量加载进内存做权限校验，所以直接 INSERT INTO mysql.user 或 UPDATE mysql.db 不会立刻起作用。
为什么 GRANT 之后应用还报 Access denied？
常见现象是执行了 GRANT SELECT ON app.* TO 'dev'@'%'，但服务连不上、查不了。根本原因不是语句写错，而是权限没“活”过来——GRANT 内部确实会触发权限重载，但只对当前连接会话生效；其他已建立的连接（包括长连接、连接池里的连接）仍用旧的内存快照。
- 新连接一定生效；老连接必须重连，或手动执行
FLUSH PRIVILEGES - 用了 HikariCP、Druid、ProxySQL 等中间件时尤其危险：连接可能复用数小时，权限变更后实际生效时间严重滞后
- MySQL 8.0+ 已禁止直接写
mysql.user表，强行 UPDATE 会报错，必须走CREATE USER/GRANT
user@host 是唯一标识，权限检查严格短路匹配
MySQL 认证和鉴权从来不是只看用户名，而是严格匹配 'user'@'host' 这个二元组。更关键的是权限检查顺序：先查 mysql.user，命中就停，不再往下查 mysql.db ——这就是「自顶向下短路匹配」。
- 例如：
'api'@'10.0.2.%'在user表中Select_priv = 'N'，但在db表中对finance库有Select_priv = 'Y'→ 他依然能查finance库（因为user表没给全局 SELECT 权，才继续往下查db表） - 但如果
user表里Delete_priv = 'Y'，那他就拥有删任意库任意行的权力，db或tables_priv里的 DELETE 权限就完全被跳过了 - 同一个用户名从不同 IP 登录，权限可能天差地别，根源就在这里
查权限别直接 SELECT 系统表，用 SHOW GRANTS
虽然你能 SELECT * FROM mysql.db WHERE User='dev' AND Db='app'，但字段含义复杂（比如权限字符串是逗号分隔的 'Select,Insert'，还有 Grant_priv、Timestamp 等辅助字段），容易误读。官方推荐方式永远是：
-
SHOW GRANTS FOR 'dev'@'%'—— 看这个账号实际拥有的全部有效权限（已合并各层） -
SHOW GRANTS FOR CURRENT_USER()—— 查当前会话身份所获得的权限，适合调试连接池行为 - 想看某库下谁有权限？用
SELECT User,Host FROM mysql.db WHERE Db='app' AND Select_priv='Y'可以，但仅限快速筛查，不建议用于权限审计
真正复杂的权限设计（比如列级控制、代理用户、角色继承），直接查表极易漏判，必须结合 SHOW GRANTS 和实际连接测试验证。
