REVOKE后权限未生效需让用户重连或执行FLUSH PRIVILEGES（仅修改系统表时需要）；注意账号host匹配、权限叠加性及列级权限残留，撤销后应SHOW GRANTS验证。
REVOKE 命令执行后权限没生效？检查当前连接用户和生效范围
MySQL 的 REVOKE 不会自动刷新当前会话的权限缓存，已登录用户的权限仍沿用旧快照。必须让目标用户重新连接，或你自己执行 FLUSH PRIVILEGES（仅当直接修改了 mysql 系统库表时才需要，正常用 REVOKE 不需要）。
- 常见错误现象：
REVOKE SELECT ON db1.* FROM 'u1'@'%';执行成功，但 u1 用现有连接仍能查表 - 正确做法：让 u1 断开重连；若在调试环境，可直接用
mysql -u u1 -p新开终端验证 -
REVOKE只影响指定账号（'u1'@'localhost'和'u1'@'%'是两个独立账号），务必核对 host 部分是否匹配 - 撤销全局权限（如
PROCESS、RELOAD）时，必须用ON *.*，写成ON db1.*无效
撤销权限时提示 “There is no such grant defined for user”
这不是报错，而是 MySQL 的“静默忽略”行为——当要撤销的权限本来就没被授予过，REVOKE 会返回警告但不中断执行。容易误以为命令失败，其实它只是什么都没做。
- 使用场景：自动化脚本中反复执行
REVOKE清理权限，无需先SHOW GRANTS判断 - 验证是否真撤销了：执行
SHOW GRANTS FOR 'u1'@'%';，结果里不应再出现对应权限行 - 注意大小写和空格：MySQL 权限名（如
INSERT）不区分大小写，但用户名和 host 必须完全一致（'U1'@'%' ≠ 'u1'@'%'） - 如果想让脚本感知“是否实际撤销”，可用
SELECT COUNT(*) FROM mysql.tables_priv WHERE User='u1' AND Table_name='t1';（需有SELECT权限查系统表）
撤销数据库级权限后，用户还能访问表？检查列级/表级残留权限
MySQL 权限是叠加的。撤销 SELECT ON db1.* 并不会清除之前单独授予的 SELECT(col1) ON db1.t1 或 SELECT ON db1.t1，这些更细粒度的权限依然有效。
- 典型坑：管理员只 revoke 了库级权限，但忘了查
mysql.columns_priv和mysql.tables_priv - 完整清理建议顺序：
REVOKE ... ON db1.t1; REVOKE ... ON db1.*; REVOKE ... ON *.*;（从细到粗） - 列级权限（如
SELECT(col_a,col_b)）无法用REVOKE SELECT ON db1.t1一并撤销，必须显式写全列名或用REVOKE ALL PRIVILEGES ON db1.t1 - 性能影响：细粒度权限越多，每次语句解析时权限检查越慢，生产环境尽量避免混用多层授权
用 DROP USER 彻底删除账号前，先确认是否依赖权限继承
DROP USER 会连带清除所有权限记录，但它不是 REVOKE 的替代方案——如果该用户被其他账号通过 WITH GRANT OPTION 授予过权限，那些下游权限不会自动失效，可能造成权限残留。
- 使用场景：彻底下线测试账号、离职人员账号
- 安全前提：先执行
REVOKE ALL PRIVILEGES, GRANT OPTION ON *.* FROM 'u1'@'%';，再DROP USER，避免意外传播 - 兼容性注意：MySQL 5.7+ 支持
DROP USER IF EXISTS，但 5.6 及更早版本不支持，脚本中需判断版本 - 最容易被忽略的一点：如果应用配置里还存着这个账号密码，
DROP USER后连接会直接报Access denied for user，而不是权限不足——排查时别只盯权限表
