必须显式列出要撤销的权限，如REVOKE SELECT ON db1.t1 FROM 'u1'@'localhost'，仅撤SELECT不影响UPDATE；需严格匹配原GRANT粒度、用户主机名及GRANT OPTION，撤销后旧连接仍保留权限，须重连验证。
REVOKE SELECT但不碰UPDATE必须显式列出权限
MySQL不会自动推导“撤SELECT但留UPDATE”，REVOKE语句必须明确写出要撤销的权限类型。写REVOKE SELECT ON db1.* FROM 'u1'@'localhost'只影响SELECT，UPDATE不受影响——前提是当初授权时SELECT和UPDATE是分开授予的，或者一起授予但你只撤其中一项。
常见错误现象：执行REVOKE ALL PRIVILEGES ON db1.* FROM 'u1'@'localhost'后发现UPDATE也没了，就是因为ALL PRIVILEGES覆盖了所有已授权限，不是“智能保留未列项”。
- 必须确保
ON子句与原始GRANT完全一致，比如原先是GRANT SELECT, UPDATE ON db1.t1 FROM 'u1'@'localhost'，那撤销就得写REVOKE SELECT ON db1.t1 FROM 'u1'@'localhost'，不能写db1.* - 如果原授权包含
GRANT OPTION，它不会被连带撤销，要单独处理：REVOKE GRANT OPTION ON db1.* FROM 'u1'@'localhost' - 权限大小写敏感：
revoke select会报错，必须大写SELECT
先查清楚用户当前有哪些权限再动手
盲目撤销容易误伤。用SHOW GRANTS FOR 'u1'@'localhost'看实际授予的语句，重点确认两点：权限是否合并授予（如GRANT SELECT, UPDATE ON db1.*），以及作用对象粒度（db1.*还是db1.t1）。
如果SHOW GRANTS返回里没有SELECT，说明该用户本来就没这个权限，执行REVOKE SELECT会报错ERROR 1147 (42000): There is no such grant defined...。
- 不要依赖
SELECT * FROM mysql.db WHERE User='u1'查权限——它只存数据库级权限，表级或列级权限在tables_priv、columns_priv里 - MySQL 8.0+若用户通过角色获得权限，
SHOW GRANTS会显示AS role_name，此时直接REVOKE SELECT无效，得先REVOKE role_name FROM 'u1'@'localhost'
撤销后旧连接仍能执行SELECT直到断开
REVOKE生效是会话级的：已建立的连接不会立刻丢掉SELECT权限，只有新连接才会按新权限校验。这意味着应用可能还在读数据，你以为撤成功了，其实只是“未来失效”。
- 验证是否真生效，别只看
Query OK，要用新连接测试：mysql -u u1 -h localhost -D db1 -e "SELECT 1" - 如果需要立即切断，只能手动
KILL对应连接，或等应用自己重连 - 不需要
FLUSH PRIVILEGES——REVOKE本身已持久化并通知权限系统，该命令只对直接修改mysql系统表的操作才需要
表级SELECT权限不能靠数据库级REVOKE覆盖
如果用户同时有SELECT ON db1.*和SELECT(col_a) ON db1.t1，只执行REVOKE SELECT ON db1.*不会动列级权限。这时候SELECT col_a FROM t1仍能跑通，但SELECT * FROM t1会报错。
这种细粒度残留权限很难一眼发现，尤其当SHOW GRANTS只显示高阶权限时。
- 查列级权限：
SELECT * FROM mysql.columns_priv WHERE User='u1' AND Host='localhost' AND Db='db1' - 撤销列级权限：
REVOKE SELECT(col_a) ON db1.t1 FROM 'u1'@'localhost' - 表级和列级权限独立存在，互不影响，必须分别处理
权限撤销不是“减法思维”，而是“精确匹配+逐层清理”。最容易被忽略的是权限作用域的嵌套关系和旧连接缓存行为——前者导致你以为撤干净了其实还漏着，后者让你误判生效时机。
