<p>REVOKE ALL PRIVILEGES ON db_name.* 有时不生效，因其仅撤销数据库级显式权限，而表级、列级、角色继承等细粒度权限需单独处理，且旧连接缓存权限、host/大小写不匹配、未重连验证等均会导致失效。</p>
REVOKE ALL PRIVILEGES ON db_name.* 为什么有时不生效
因为这条命令只撤销“数据库级”显式授权，但用户可能还持有更细粒度的权限（如表级、列级、存储过程），或者通过角色继承了权限。MySQL 不会自动递归清理这些关联权限。
常见现象：执行 REVOKE ALL PRIVILEGES ON app.* FROM 'dev'@'%' 后，SHOW GRANTS FOR 'dev'@'%' 看似清空了，但用户仍能查 app.users 表——很可能是当初用 GRANT SELECT ON app.users 单独授过权，或该用户属于有 SELECT 权限的角色。
- 先查清所有来源：
SHOW GRANTS FOR 'dev'@'%';和SHOW GRANTS FOR 'dev'@'%' USING 'role_name'; - 检查列级权限：
SELECT * FROM mysql.columns_priv WHERE User='dev' AND Host='%' AND Db='app'; - 若有结果，必须逐条撤销，例如：
REVOKE SELECT(col_a) ON app.conf FROM 'dev'@'%'; - 若用了角色，需同时解绑：
REVOKE 'reader_role' FROM 'dev'@'%';
撤销数据库权限时 host 和大小写必须完全一致
MySQL 把 'user'@'10.0.1.%' 和 'user'@'%' 当作两个不同账号；INSERT 和 insert 也被视为不同权限名。写错任一字段，REVOKE 就静默失败或报 ERROR 1141，而你可能根本没意识到没撤掉。
- 务必用
SHOW GRANTS FOR 'u'@'h'复制原始授权语句中的完整格式（包括引号、反引号、大小写） - 含特殊字符的库名/表名必须加反引号：
REVOKE SELECT ON `my-db`.`log table` FROM 'u'@'h'; - host 不匹配是高频错误点：比如原授权是
'dev'@'192.168.5.0/24'，就不能用'dev'@'%'撤销
撤销后旧连接还能继续操作，重连才是验证关键
REVOKE 成功只是更新了服务端权限表，已建立的连接（尤其是应用连接池里的长连接）仍持有旧权限快照。这不是 bug，是设计如此。
- 验证是否真生效，必须新开连接：
mysql -u dev -h db-host -p -e "SELECT * FROM app.users LIMIT 1;" - 生产环境不能等连接自然超时，得滚动重启应用，或让应用主动释放并重建连接
- MySQL 8.0+ 若启用了角色，可在当前会话执行
SET ROLE NONE;临时丢弃角色权限，但不会影响其他会话
FLUSH PRIVILEGES 到底要不要加
正常用 REVOKE 命令操作，不需要 FLUSH PRIVILEGES；它只在你绕过 REVOKE 直接 UPDATE mysql.db 等系统表时才强制需要。但加了也不报错，老版本（如 MySQL 5.7）建议加上以防缓存未刷新。
- MySQL 8.0+：不加也立即生效（服务端权限变更实时生效）
- MySQL 5.7 及更早：加
FLUSH PRIVILEGES;更稳妥 - 别为了“保险”就无脑加——它会强制重载整个权限缓存，对高并发实例有短暂性能抖动
真正容易被跳过的不是语法，而是验证环节：看到 Query OK 就以为完事，结果权限还在跑。重连测试这一步，比写对那条 REVOKE 语句更重要。
