MySQL 中执行 REVOKE 撤销权限时，必须与原始 GRANT 授权语句完全一致，尤其要严格匹配权限名称、ON 作用范围以及 'user'@'host' 三个关键点；同时还要注意大小写敏感、授权粒度一致，GRANT OPTION 与动态权限也需要单独撤销；权限回收后应通过新连接重新验证，不能依赖旧连接或误以为 FLUSH PRIVILEGES 就能立即生效。

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

撤销某个数据库权限时，不要简单理解为“把这个库的访问权限一次性删除”，更准确的说法是：通过 REVOKE 精确移除对应的那条 GRANT 授权记录。MySQL 不会自动帮你推断或模糊匹配，因此想让 REVOKE 正常生效，以下三项必须与原授权严格对应：权限名、ON 后面的作用范围，以及 'user'@'host'。只要其中任意一项不一致，命令就可能悄悄失效，例如主机名不匹配，或者直接返回 ERROR 1141，表示系统没有找到可撤销的授权记录。

• SELECT 不能写成 select —— 权限名称区分大小写
• app_log.* 与 app_log.t1 属于不同授权层级，不能混用；如果当初是表级授权，就不能用库级权限撤销
• 'dev'@'10.0.1.%' 如果写成 'dev'@'%'，即使用户实际上可以登录，REVOKE 作用的也是另一个逻辑账户
• 当数据库名称中包含横线或空格时，必须使用反引号包裹：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。

• 如果用户还通过角色获得了权限（例如 REVOKE 'reader_role' FROM 'analyst'@'%'），那么撤销直接授权并不会影响角色继承来的权限
• ALL PRIVILEGES ON report_db.* 也不会清除列级权限，例如 SELECT(col_a) ON report_db.users，这类权限必须单独处理
• 不要轻易使用 REVOKE ALL PRIVILEGES ON *.* 试图“一次清空”——它可能会连同用户在 mysql、performance_schema 等系统数据库上的权限一起移除，从而引发后续管理问题

撤销后 SELECT 还能执行？旧连接不会立即应用新权限

REVOKE 执行成功并返回 Query OK，并不意味着应用程序会立刻失去相应权限。MySQL 的权限校验通常发生在连接建立阶段，因此已经存在的连接，尤其是连接池中的长连接，往往仍然持有旧的权限快照。此时你看到“还能 INSERT”或“还能 SELECT”，通常不是因为命令没执行，而是因为客户端连接还没有刷新。

• 确认撤销是否真正生效，第一步不要只看执行结果，而应立即运行：SHOW GRANTS FOR 'analyst'@'%'，检查输出中是否已经移除了对应授权
• 第二步必须使用新连接进行测试：mysql -u analyst -h db-host -p -e "INSERT INTO report_db.t1 VALUES (1)"
• 在生产环境中，应通过滚动重启应用或强制连接池重建连接来刷新权限；如果启用了角色，MySQL 8.0+ 还可在会话内执行 SET ROLE NONE
• FLUSH PRIVILEGES 在 MySQL 8.0+ 中通常不是必须步骤，即使执行也不会报错；真正决定权限是否立即体现的关键，仍然是让客户端重新连接，而不是单纯刷新缓存

权限残留往往隐藏在 mysql.tables_priv 或 mysql.columns_priv 中

很多人看到 SHOW GRANTS 中没有相关记录，就以为权限已经清理干净，但实际情况未必如此。更细粒度的权限，例如表级权限、列级权限，甚至存储过程级权限，通常保存在 mysql.tables_priv、mysql.columns_priv 等系统表中，而不是简单地出现在 mysql.db 表里。

• 检查列级权限是否仍然存在：SELECT * FROM mysql.columns_priv WHERE User='analyst' AND Host='%' AND Db='report_db';
• 检查表级权限：SELECT * FROM mysql.tables_priv WHERE User='analyst' AND Host='%' AND Db='report_db';
• 不要直接执行 DELETE FROM mysql.tables_priv —— 这样做可能破坏权限缓存一致性，而且在 MySQL 8.0+ 的角色机制下往往并不可靠
• 最安全、最规范的做法仍然是使用与授权粒度对应的 REVOKE 语句，例如：REVOKE SELECT(col_a) ON report_db.users FROM 'analyst'@'%';

在 MySQL 权限回收场景中，最容易被忽略但最关键的一步，其实就是“重连后验证”。很多人看到 Query OK 就认为撤销数据库权限已经完成，结果到了生产环境中却发现权限变更并未真正生效。