不加 CASCADE 时 REVOKE 会因依赖对象存在而报错；CASCADE 仅清理直接依赖该权限的对象权限，不删除对象本身，且各数据库实现差异大。
REVOKE 语句不加 CASCADE 时，被依赖对象会报错
直接执行 revoke 撤销一个用户对表的 select 权限，但该用户已用这个表创建了视图，postgresql 或 oracle 会拒绝操作，并抛出类似 dependent objects exist 的错误。这不是 bug，是权限系统在保护依赖链完整性。
实操建议：
- 先查依赖：PostgreSQL 用
SELECT * FROM pg_depend WHERE refobjid = 'schema.table'::regclass;；Oracle 查ALL_DEPENDENCIES - 若确认可断开依赖，加
CASCADE强制回收：REVOKE SELECT ON schema.table FROM user_name CASCADE; - 不加
CASCADE是安全默认，但容易卡在“明明只动一张表，却撤不了权”的现场
级联回收（CASCADE）到底影响哪些对象
CASCADE 不是递归删所有相关权限，它只清理「直接依赖当前权限对象」的那些对象上的权限或定义。比如：用户 A 有表 T 的 SELECT，又基于 T 创建了视图 V；你对 T 执行 REVOKE ... CASCADE，V 本身不会被删，但 A 在 V 上的 SELECT 权限会被连带收回（因为 V 的执行依赖 T 的权限）。
常见误区：
- 误以为
CASCADE会删除视图、函数等对象本身 —— 不会，只动权限和可执行性 - 误以为它会回收 A 授予他人的权限 —— 不会，
REVOKE默认只处理直接授予目标用户的权限 - MySQL 不支持
CASCADE关键字，它的REVOKE本身就是“非级联”的，依赖对象失效需手动处理
撤销 WITH GRANT OPTION 后，下游授权立即失效
如果用户 A 被授予 SELECT ON table TO B WITH GRANT OPTION，之后 B 又授给 C；当你对 A 执行 REVOKE SELECT ON table FROM A，B 和 C 的权限不会自动消失 —— 除非你加 CASCADE，且数据库支持该语义（PostgreSQL 支持，Oracle 需用 REVOKE ... CASCADE CONSTRAINTS）。
关键点：
- 没
WITH GRANT OPTION的原始授权，撤掉后不影响下游 - 有
WITH GRANT OPTION但没加CASCADE，只断 A 的权限，B/C 仍能用（但无法再转授） - 加
CASCADE后，B 的权限被撤，C 的权限也因失去来源而失效（PostgreSQL 行为） - 这条链式失效不可逆，且不产生日志提示，容易漏查
不同数据库对 REVOKE CASCADE 的兼容性差异大
同一句 REVOKE ... CASCADE 在 PostgreSQL、Oracle、SQL Server 能跑，在 MySQL 直接语法报错。更麻烦的是，即使都支持 CASCADE，它实际清理的范围也不一致 —— 比如 SQL Server 的 CASCADE 会同时撤回 EXECUTE 权限对存储过程的影响，而 PostgreSQL 不管过程体内的权限调用。
实操建议：
- 上线前必须在目标环境验证语句：建测试用户、授予权限、造依赖对象、再
REVOKE CASCADE - 避免跨库写自动化脚本，尤其是涉及权限回收的运维任务
- PostgreSQL 15+ 对
CASCADE增加了RESTRICT模式（默认），想强制级联必须显式写CASCADE，旧版本默认行为反而更激进
级联不是开关，是权限依赖图上的一次局部剪枝 —— 图结构越复杂，剪哪根边、是否断连通，得看数据库怎么定义“依赖”。别信文档里那句“自动处理”，先看执行计划或依赖查询结果。
