应先检查依赖、连接和调用，再转移所有权或重置权限，最后按数据库规范执行删除命令。PostgreSQL用REASSIGN OWNED+DROP USER；MySQL需全称匹配并FLUSH PRIVILEGES；SQL Server须先DROP USER后DROP LOGIN。
PostgreSQL 中如何安全删除闲置的 user？
直接执行 drop user 很危险——如果该用户还拥有数据库、表、函数或正在连接，命令会失败并报错 error: role "xxx" cannot be dropped because some objects depend on it。必须先解除依赖，再删。
- 先查依赖：
SELECT * FROM pg_depend WHERE refobjid = (SELECT oid FROM pg_roles WHERE rolname = 'old_user'); - 重点看
classid对应的系统表（如pg_class是表/索引，pg_database是库），用SELECT relname FROM pg_class WHERE oid = objid;定位具体对象 - 常见解法：把对象所有权转给
postgres或其他活跃管理员，用REASSIGN OWNED BY old_user TO new_admin; - 执行完再删：
DROP USER old_user;
MySQL 删除用户时为什么 DROP USER 报 ERROR 1396 (HY000)？
这是 MySQL 的典型“残留授权记录”问题：用户被 DELETE FROM mysql.user 手动删过，但权限表没同步清理，或者主机名匹配不精确（比如创建时是 'user'@'192.168.%'，删除时写了 'user'@'%'）。
- 务必用
SELECT User, Host FROM mysql.user WHERE User = 'old_user';确认完整Host值 - 删除必须带全称：
DROP USER 'old_user'@'192.168.%';，不能省略@'host' - 删完运行
FLUSH PRIVILEGES;，否则旧连接可能仍能登录 - 避免手动删
mysql.user表——MySQL 8.0+ 已禁用该操作，5.7 及以前也极易破坏权限一致性
SQL Server 的 sp_dropuser 已废弃，现在该用什么？
sp_dropuser 在 SQL Server 2005 后就标记为废弃，2012+ 版本虽仍可用但不推荐；真正该用的是 DROP USER（数据库级）配合 DROP LOGIN（实例级），且顺序不能错。
- 先删数据库用户：
DROP USER [old_user];（在对应数据库上下文中执行） - 再删登录名：
DROP LOGIN [old_user];（在master数据库中执行） - 如果报错
The database principal owns a schema，说明用户是某 schema 的 owner，得先用ALTER AUTHORIZATION ON SCHEMA::[schema_name] TO dbo;转移所有权 - 注意：Windows 登录名（如
DOMAIN\user）和 SQL 登录名处理方式一致，但不能用通配符匹配删除
删用户前最容易被忽略的三个检查点
不是所有“闲置”都真的可删。很多故障源于删了还在被应用、定时任务或监控脚本暗中调用的账号。
- 查当前连接：
SELECT * FROM pg_stat_activity WHERE usename = 'old_user';（PostgreSQL）或SELECT * FROM sys.dm_exec_sessions WHERE login_name = 'old_user';（SQL Server） - 查历史审计日志：MySQL 的
general_log或 PostgreSQL 的log_statement = 'all'日志里搜用户名，确认最近 30 天无调用 - 查应用配置文件和 CI/CD 脚本：搜索代码仓库里所有含
old_user的.env、application.yml、SQL 迁移脚本，别只盯着数据库本身
删用户不是单点操作，它牵扯权限链、对象归属、外部依赖。漏掉任意一环，轻则功能异常，重则数据不可写。动手前花五分钟查清楚，比出事后再恢复快得多。
