MySQL权限分全局、数据库、表、列及存储过程级，按从具体到宽泛匹配，但不支持显式DENY；新建用户默认无权，需显式授权；'user'@'%'与'localhost'是独立账号，匹配方式和优先级不同；GRANT后活跃会话不自动更新权限；必须用DROP USER删除用户并清理关联权限。
MySQL 中的权限层级是怎么划分的
MySQL 的权限不是扁平的，而是分层的：全局（GRANT OPTION）、数据库级（test.*）、表级（test.users）、列级（SELECT(name, email)）、甚至存储过程/函数级。权限生效时，MySQL 会从最具体层级向上匹配，但**高一层级的拒绝（DENY）不被支持**——只有显式 REVOKE 或未授权才等效于“无权”。
- 新建用户默认没有任何权限，哪怕有
USAGE（仅登录能力）也得显式授予 -
mysql.user表只存全局权限；库/表级权限存在mysql.db、mysql.tables_priv等系统表中 - 使用
SHOW GRANTS FOR 'u'@'h'查看实际生效权限，比查系统表更可靠
创建用户时 host 部分写 % 还是 localhost 有啥区别
'user'@'%' 允许该用户从任意 IP 连接（包括本机），而 'user'@'localhost' **仅匹配 Unix socket 或 TCP 到 127.0.0.1 的连接**，且在权限检查时优先级更高。这两者是完全独立的账号，可能密码不同、权限不同。
- Linux 下用
mysql -u user默认走 socket，匹配localhost；加-h 127.0.0.1就走 TCP，匹配%或127.0.0.1 - 不要盲目用
'user'@'%'配合强密码来替代localhost账号——某些运维脚本或监控工具硬编码了localhost连接方式 - 若需限制仅内网访问，用
'user'@'192.168.1.%'比%更安全
GRANT 语句执行后为什么权限没立刻生效
多数情况下权限会立即生效，但有两个常见例外：
- 如果用户当前已有活跃连接，新授予权限**不会自动同步到该会话**，需断开重连或执行
FLUSH PRIVILEGES（不推荐，仅当直改系统表后才需要） - 若启用了
read_only=ON，非 super 用户无法执行GRANT，会报错ERROR 1290 (HY000): The MySQL server is running with the --read-only option - MySQL 8.0+ 引入角色（
ROLE），角色权限变更后，已激活该角色的会话也不会自动更新，需重新SET ROLE
删除用户用 DROP USER 还是 DELETE FROM mysql.user
必须用 DROP USER 'u'@'h'。直接 DELETE FROM mysql.user 不仅不刷新权限缓存，还会留下残缺状态：
DROP USER 'app_rw'@'10.10.%.%';
-
DROP USER自动清理mysql.db、mysql.tables_priv等关联权限记录 - 手动删
mysql.user行后，必须跟FLUSH PRIVILEGES，否则下次重启可能因元数据不一致报错 - MySQL 8.0+ 中，
DROP USER还会自动撤销该用户持有的所有角色（REVOKE ROLE ... FROM）
权限系统真正复杂的地方不在语法，而在 host 匹配逻辑和会话缓存行为——这两个点线上出问题时最难排查。
