MySQL 权限管理四大陷阱：①转发权限需显式加 WITH GRANT OPTION；②’localhost’ 与 ’127.0.0.1’ 是不同账号，权限不互通；③REVOKE 后活跃连接权限仍有效，需 KILL CONNECTION 生效；④MySQL 8.0 默认认证插件不兼容旧客户端，需指定 IDENTIFIED WITH。
GRANT 语句没加 WITH GRANT OPTION 却想转发权限
很多人执行 GRANT SELECT ON db.* TO 'user'@'%' 后，以为该用户能帮别人授权，结果 GRANT SELECT ON db.tbl TO 'other'@'localhost' 直接报错 ERROR 1045 (28000): Access denied for user。MySQL 默认禁止权限转授，必须显式加上 WITH GRANT OPTION 才行。
实操建议：
- 只在真正需要代理授权的账号上加
WITH GRANT OPTION，比如 DBA 助理账号 - 加完记得刷新：执行
FLUSH PRIVILEGES（虽然多数情况自动生效，但旧版本或特殊部署下仍需手动刷） - 注意：拥有
WITH GRANT OPTION的用户，也能把自己没有的权限（比如CREATE USER）转授出去——只要其上级授予了该权限并带此选项
Host 匹配规则被忽略导致连接失败
'user'@'localhost' 和 'user'@'127.0.0.1' 在 MySQL 里是两个完全不同的账号，权限互不影响。本地用 mysql 客户端默认走 socket 连接（匹配 localhost），而用 IP 连接（如 mysql -h 127.0.0.1）则匹配 127.0.0.1 ——如果只给前者授了权，后者就会报 Access denied。
常见误区：
- 测试时用
localhost成功，上线用容器或代理连127.0.0.1就失败 - 误以为
'user'@'%'能覆盖所有地址，其实它不匹配localhost（Unix socket 场景优先级更高） - 防火墙 或云厂商安全组放行了 端口，但 MySQL 没开远程 host 权限，白忙一场
REVOKE 后权限没立即失效
执行 REVOKE DELETE ON db.* FROM 'user'@'%' 后，已建立的连接仍保有旧权限，直到断开重连。这不是 bug，是 MySQL 的设计：权限检查发生在命令执行时，但权限缓存存在于连接会话中。
关键点：
- 活跃连接不会因
REVOKE或DROP USER立即中断，也不会丢权限 - 要立刻生效，只能杀掉连接：
KILL CONNECTION（查SHOW PROCESSLIST获取 ID） -
FLUSH PRIVILEGES对REVOKE无效——它只重载 mysql.user 表，而REVOKE已直接修改了权限表
创建用户时没指定 IDENTIFIED WITH 导致认证失败
MySQL 8.0+ 默认认证插件是 caching_sha2_password，但很多老客户端（如某些 Python MySQLdb、旧版 Navicat、PHP 5.x mysqli）不支持。如果建用户时没显式指定 IDENTIFIED WITH mysql_native_password，就可能连得上但执行任何语句都报 ERROR 1045 或卡在握手阶段。
正确写法示例：
CREATE USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd123'; GRANT SELECT, INSERT ON mydb.* TO 'app'@'%';补充说明：
- MySQL 5.7 及更早版本默认用
mysql_native_password，升级到 8.0 后新建用户行为变了 - 也可以全局降级：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx';，但不推荐长期这么做 - 用
SELECT plugin FROM mysql.user WHERE User='xxx';查当前用户的认证插件
权限配置最麻烦的地方不在语法，而在“谁在什么上下文里以什么方式连接”。同一个用户名，localhost vs 127.0.0.1 vs 192.168.1.100 是三套权限体系；同一个 GRANT 语句，在 MySQL 5.7 和 8.0 下生效逻辑也可能不同。动手前先确认版本、连接方式、客户端能力，比反复试错快得多。
