revoke 必须与 grant 完全一致才能撤销权限，包括权限名、on 范围和 'user'@'host' 三处严格匹配；大小写敏感、粒度一致、grant option 和动态权限需单独处理；撤销后需新连接验证，不可依赖旧连接或 flush privileges。
REVOKE ON db_name.* 必须和当初 GRANT 完全一致
撤销特定数据库权限，不是“删掉这个库的访问”，而是“删掉某条 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'@'%'），REVOKE直接授权的部分不影响角色权限 -
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”，不是命令没执行，而是连接没刷新。
- 验证是否真生效，第一步不是看返回值，而是立刻执行：
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'@'%';
真正容易被跳过的，是重连验证这一步——人看到 Query OK 就以为完事了，结果权限变更在生产环境形同虚设。
