必须先清理依赖对象再执行 DROP ROLE（等价于 DROP USER），否则因对象依赖报错；推荐顺序为：REASSIGN OWNED → REVOKE 权限 → 确认无依赖 → DROP ROLE。
执行 DROP USER 前必须确认依赖关系
直接运行 DROP USER 很可能报错，比如 ERROR: role "xxx" cannot be dropped because some objects depend on it。PostgreSQL（以及多数主流数据库）默认不允许删除仍拥有对象的用户，哪怕你只是想清掉一个闲置账号。
真正要删掉用户，得先处理它“名下”的东西：表、函数、序列、默认权限、甚至其他用户的 GRANT 记录。不查清楚就硬删，轻则失败，重则导致应用查询突然报错——因为某个视图或函数的 owner 被意外清空了。
- 用
SELECT * FROM pg_depend WHERE refobjid = (SELECT oid FROM pg_roles WHERE rolname = 'xxx');快速定位该用户创建的对象 - 更实用的是
SELECT nspname, relname, relkind FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace WHERE relowner = (SELECT oid FROM pg_roles WHERE rolname = 'xxx');查它拥有的表/视图/序列 - 别漏掉
pg_proc（函数）、pg_default_acl（默认权限）、pg_shdepend（共享对象依赖，如数据库级权限）
DROP USER 和 DROP ROLE 实际上是同一个命令
PostgreSQL 里 USER 是 ROLE 的别名，DROP USER xxx 完全等价于 DROP ROLE xxx。没有“用户专属”清理逻辑，也不存在“只删登录权限不删角色”的中间态。
这意味着：如果你用 CREATE USER 创建的账号，它本质就是个带 LOGIN 属性的 ROLE；而用 CREATE ROLE ... LOGIN 创建的，行为完全一致。删的时候别被名字迷惑。
- 检查是否真有
LOGIN权限：SELECT rolname, rolcanlogin FROM pg_roles WHERE rolname = 'xxx'; - 如果
rolcanlogin是f，说明它本来就不能登录，但依然可能拥有对象——照样要走依赖清理流程 - 某些旧脚本里写
DROP USER IF EXISTS，注意IF EXISTS只避免“用户不存在”报错，不跳过依赖检查
安全清理的推荐顺序：改 owner → 清权限 → 再删角色
最稳妥的做法不是一上来就 DROP，而是把该用户名下的对象所有权移交出去，再清理残留权限，最后删角色。这样既保留数据可用性，又避免误删引发连锁故障。
- 批量移交表所有权：
REASSIGN OWNED BY xxx TO postgres;（建议先用postgres或运维专用角色承接） - 清空它授予别人的权限：
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM xxx;，并补上REVOKE ALL ON DATABASE xxxdb FROM xxx;等场景化语句 - 删角色前，再跑一次
SELECT * FROM pg_depend WHERE refobjid = (SELECT oid FROM pg_roles WHERE rolname = 'xxx');确认返回空 - 最后执行
DROP ROLE xxx;—— 这时成功率接近 100%
MySQL / SQL Server 用户注意语法和行为差异
如果你在 MySQL 里执行 DROP USER，它会自动回收权限，但不会碰对象所有权（表还是归原用户所有，只是账号没了），可能导致后续 SHOW CREATE TABLE 显示已删用户为 owner，或触发 DEFINER 错误。SQL Server 更麻烦：DROP USER 不等于删 LOGIN，用户删了，登录名还挂着，且数据库用户可能被 schema 拥有者引用，删前得先 ALTER AUTHORIZATION ON SCHEMA::xxx TO dbo;。
- MySQL：删用户后务必检查
information_schema.TABLES中TABLE_SCHEMA和TABLE_NAME对应的CREATE_OPTIONS是否含DEFINER引用 - SQL Server：用
SELECT dp.name, dp.type_desc, dp.authentication_type_desc FROM sys.database_principals dp WHERE dp.sid IN (SELECT sid FROM sys.server_principals WHERE name = 'xxx');查是否仍有映射 - 跨库迁移或统一运维时，别假设
DROP USER行为一致——连错误码都不同，MySQL 是ERROR 1396 (HY000)，PG 是2BP01，SQL Server 是15138
依赖关系不是一次性检查就能覆盖全部，特别是通过 SECURITY DEFINER 函数、物化视图、外部数据包装器（FDW）或扩展（如 pg_cron 任务）引入的隐式绑定，容易漏掉。删之前最好在测试环境完整回放一遍操作链。
