应先检查依赖、连接和调用，再转移所有权或重置权限，最后按数据库规范执行删除命令。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 迁移脚本，别只盯着数据库本身

删用户不是单点操作，它牵扯权限链、对象归属、外部依赖。漏掉任意一环，轻则功能异常，重则数据不可写。动手前花五分钟查清楚，比出事后再恢复快得多。