mysql权限管理的基本概念与用户管理

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 匹配逻辑和会话缓存行为——这两个点线上出问题时最难排查。