执行 GRANT 失败是当前登录账号缺少 GRANT OPTION 权限；REVOKE 后需 FLUSH PRIVILEGES 并重连才生效；权限按 user@host 精确匹配且叠加，SHOW GRANTS 可能遗漏多 host 记录。
GRANT 执行失败：Access denied 是谁没权限？
不是目标用户没权限，而是你当前登录的账号缺少 GRANT OPTION 权限——这是执行 GRANT 的硬性前提。
- 普通账号执行
GRANT会直接报错：Access denied; you need (at least one of) the GRANT OPTION privilege(s) - 只有
root或被显式授予GRANT OPTION ON *.*的账号才能授权他人 - MySQL 8.0+ 中，
CREATE USER和GRANT分离更严格：若目标用户不存在，GRANT ... IDENTIFIED BY仍可创建（仅限首次），但已存在用户必须用ALTER USER改密，否则报错
REVOKE 后权限还不生效？别只盯着语句
REVOKE 成功只是改了权限表，不等于用户立刻失去权限——旧连接缓存未清，新连接才走新规则。
- 必须手动执行
FLUSH PRIVILEGES;，尤其在高并发、主从复制或连接池环境，MySQL 不保证自动重载 - 用户当前会话仍保留原权限，需断开重连才受新策略约束
- 注意 host 匹配粒度：
'user'@'localhost'和'user'@'127.0.0.1'是两条独立记录，REVOKE只影响显式指定的那一行
授什么权？按场景选最小集，别碰 ALL PRIVILEGES
生产库上给 ALL PRIVILEGES 等同于交出数据库控制权，绝大多数业务根本不需要 DROP、CREATE、FILE 这类高危权限。
- Web 应用后端：通常只需
SELECT, INSERT, UPDATE, DELETE，禁用DROP和ALTER - 报表/分析账号：限制为
SELECT，再加 IP 白名单（如'analyst'@'192.168.5.%'） - 列级授权虽支持（如
GRANT SELECT(name,email) ON users TO 'api'@'%'），但会增加权限检查开销，非强需求不建议启用 - MySQL 8.0+ 角色管理更安全，但角色本身不能自动转授，需显式加
WITH ADMIN OPTION
权限查不全？SHOW GRANTS 可能漏掉 host 多条目
SHOW GRANTS FOR 'user'@'host' 只显示匹配该完整 user@host 的权限，而一个用户名可能对应多个 host 记录，权限是叠加的。
- 先查用户存在情况：
SELECT User, Host FROM mysql.user WHERE User = 'app_user'; - 再逐条检查：
SHOW GRANTS FOR 'app_user'@'%';、SHOW GRANTS FOR 'app_user'@'10.0.0.5'; -
USAGE是默认空权限状态，出现在SHOW GRANTS结果里说明该记录尚未授任何实际权限
