直接执行DELETE不能满足审计需求，因其不记录操作人、被删行及删前数据；事务日志不可读且无业务上下文；必须用存储过程在单事务内通过RETURNING捕获旧值并写入结构化审计表。
为什么直接执行 DELETE 不能满足审计需求
因为标准 DELETE 语句不记录谁删的、删了哪些行、删前数据长什么样。数据库事务日志（如 SQL Server 的 LDF 或 MySQL 的 binlog）虽有记录，但不可读、不可查询、不带业务上下文（比如操作人ID、终端IP）。审计要求的是可追溯、可关联、可告警的结构化日志，必须在应用层或存储过程里显式插入日志表。
如何用存储过程封装带审计的 DELETE（以 PostgreSQL 为例）
核心思路是：把原 DELETE 拆成两步——先用 RETURNING * 捕获待删行，再用 INSERT INTO audit_log 记录，最后才真正删除。注意必须在同一个事务中完成，否则存在日志写入成功但删除失败的不一致风险。
常见错误现象：ERROR: cannot use RETURNING in a cursor declaration（在游标中误用 RETURNING）、audit_log 表字段类型与源表不匹配导致插入失败、未加事务导致日志与删除脱节。
- 日志表至少包含：
id、table_name、operation（'DELETE'）、old_data（JSONB类型，存整行旧值）、operator_id（传入参数）、ip_address（可选，从current_setting('app.client_ip', true)获取）、created_at - 存储过程参数建议显式声明：
IN p_table_name TEXT（慎用动态表名！应限定白名单）、IN p_condition TEXT（更安全的做法是用WHERE id = $1这类确定条件，避免拼接 SQL） - PostgreSQL 中推荐用
WITH deleted AS (DELETE FROM users WHERE id = $1 RETURNING *) INSERT INTO audit_log (...) SELECT ..., to_jsonb(deleted.*) ... FROM deleted;
MySQL 和 SQL Server 的关键差异点
MySQL 不支持 DELETE ... RETURNING（8.0.23+ 才引入，且语法不同），必须改用临时表或触发器；SQL Server 虽支持 OUTPUT DELETED.*，但无法直接插入 JSON，需用 FOR JSON AUTO 或拼接字符串，性能开销更大。
使用场景差异：
- MySQL：优先考虑用
BEFORE DELETE触发器写日志（简单但无法获取调用者信息），或改用应用层双写（先SELECT ... FOR UPDATE，再INSERT INTO log，再DELETE） - SQL Server：可用
OUTPUT INTO #temp+ 循环插入日志表，但大表删除时易锁表；sys.dm_exec_sessions可查login_name，但拿不到 HTTP Header 里的真实用户ID，得靠应用层透传 - 所有数据库都需注意：审计日志表本身要建索引（如
(table_name, created_at)），否则查历史删操作会越来越慢
容易被忽略的权限与性能陷阱
存储过程执行时用的是调用者权限（DEFINER vs INVOKER），若用 DEFINER = 'audit_user'，该用户必须对日志表有 INSERT 权限，且对目标表有 DELETE 权限——但很多 DBA 只给了应用账号 SELECT/INSERT，忘了加 DELETE，导致过程报错 permission denied for table xxx。
性能影响比想象中大：每删 1 行，多一次日志表 INSERT + 索引更新。批量删除（如 WHERE status = 'archived'）时，建议限制单次最多删 1000 行，并在循环中加 COMMIT（但会破坏原子性），或者接受延迟审计（异步写日志表，用消息队列解耦）。
真正难处理的是外键级联删除——ON DELETE CASCADE 触发的子表删除不会经过你的存储过程，也不会记日志。要么禁用级联，改用存储过程手动删子表并记日志；要么在子表也建触发器，但维护成本陡增。
