如何撤销MySQL用户的指定数据库权限

REVOKE 必须与 GRANT 完全一致才能撤销权限，包括权限名、ON 范围和 'user'@'host' 三处严格匹配；大小写敏感、粒度一致、GRANT OPTION 和动态权限需单独处理；撤销后需新连接验证，不可依赖旧连接或 FLUSH PRIVILEGES。

REVOKE ON db_name.* 必须和当初 GRANT 完全一致

撤销特定数据库权限，不是“删掉这个库的访问”，而是“删掉某条 GRANT 记录”。MySQL 不会自动匹配或推导——REVOKE 必须在三处完全对齐：权限名、ON 范围、'user'@'host'。任意一处写错，命令可能静默失败（比如主机名不匹配），或直接报错 ERROR 1141（找不到对应授权）。

1. SELECT 不能写成 select —— 权限名大小写敏感
2. app_log.* 和 app_log.t1 是不同授权粒度，不能混用；当初授的是表级，就不能用库级去撤
3. 'dev'@'10.0.1.%' 写成 'dev'@'%'，哪怕用户真实连得进来，REVOKE 也作用在另一个逻辑账号上
4. 数据库名含横线或空格时，必须用反引号包裹：REVOKE SELECT ON `my-db`.* FROM 'u'@'h';

ALL PRIVILEGES 不等于“所有权限”，GRANT OPTION 得单独处理

想清空一个用户对 report_db 的全部权限，写 REVOKE ALL PRIVILEGES ON report_db.* FROM 'analyst'@'%' 是对的；但如果你当初授权时加了 WITH GRANT OPTION，这条命令不会把它撤掉——必须显式加上：

REVOKE ALL PRIVILEGES, GRANT OPTION ON report_db.* FROM 'analyst'@'%';

另外注意：ALL PRIVILEGES 不包含 GRANT OPTION，也不包含 MySQL 8.0+ 的动态权限（如 BACKUP_ADMIN），这些都得单独 REVOKE。

1. 如果用户还通过角色继承了权限（如 REVOKE 'reader_role' FROM 'analyst'@'%'），REVOKE 直接授权的部分不影响角色权限
2. ALL PRIVILEGES ON report_db.* 不会撤掉列级权限（如 SELECT(col_a) ON report_db.users），那些得单独处理
3. 别用 REVOKE ALL PRIVILEGES ON *.* 试图“一劳永逸”——它会把用户在 mysql、performance_schema 等系统库的权限也干掉，可能导致后续管理异常

撤销后 SELECT 还能跑？旧连接不生效新权限

REVOKE 成功返回 Query OK，不代表应用立刻失去权限。MySQL 权限检查发生在连接建立时，已存在的连接（尤其是连接池里的长连接）仍持有旧权限快照。你看到的“还能 INSERT”，不是命令没执行，而是连接没刷新。

1. 验证是否真生效，第一步不是看返回值，而是立刻执行：SHOW GRANTS FOR 'analyst'@'%'，确认输出里已剔除对应行
2. 第二步必须用新连接测试：mysql -u analyst -h db-host -p -e "INSERT INTO report_db.t1 VALUES (1)"
3. 生产环境需滚动重启应用，或强制连接池重建连接；MySQL 8.0+ 可在会话内执行 SET ROLE NONE（若启用了角色）
4. FLUSH PRIVILEGES 在 MySQL 8.0+ 中非必需，但加了不报错；真正关键的是让客户端重连，不是刷缓存

权限残留常藏在 mysql.tables_priv 或 mysql.columns_priv 里

你以为 SHOW GRANTS 没了就干净了？不一定。细粒度权限（表级、列级、甚至存储过程级）往往存在 mysql.tables_priv、mysql.columns_priv 表中，mysql.db 表查不到。

1. 查列级权限是否存在：SELECT * FROM mysql.columns_priv WHERE User='analyst' AND Host='%' AND Db='report_db';
2. 查表级权限：SELECT * FROM mysql.tables_priv WHERE User='analyst' AND Host='%' AND Db='report_db';
3. 不要直接 DELETE FROM mysql.tables_priv —— 这会破坏权限缓存一致性，且 MySQL 8.0+ 的角色模型会让这类操作失效
4. 最稳妥的方式仍是用 REVOKE 对应粒度语句，例如：REVOKE SELECT(col_a) ON report_db.users FROM 'analyst'@'%';

真正容易被跳过的，是重连验证这一步——人看到 Query OK 就以为完事了，结果权限变更在生产环境形同虚设。