必须提前配置审计功能才能查到“谁删的”，SQL Server、MySQL、PostgreSQL 原生审计均默认关闭，需手动启用并验证；未开启则无法追溯操作者。
没开审计就别指望查到“谁删的”——SQL Server、MySQL、PostgreSQL 的原生审计功能都必须提前配置，且默认全关。
SQL Server 审计必须显式创建并启用 server audit + database audit specification
SQL Server 不像 Linux 日志那样默认记录所有操作。audit 是独立组件，需两步手动搭：先建 SERVER AUDIT（定义日志输出位置和策略），再建 DATABASE AUDIT SPECIFICATION（指定监控哪张表、哪些操作）。漏掉任意一步，sys.fn_get_audit_file() 就只能返回空结果。
-
SERVER AUDIT必须用TO FILE或TO SECURITY LOG指定落盘路径，FILEPATH目录得让 SQL Server 服务账户有写权限，否则启动失败但不报错 -
DATABASE AUDIT SPECIFICATION中的ADD(DELETE ON dbo.Users BY [public])表示监控所有用户对 Users 表的删除，不能写成ADD(DELETE)—— 那只会捕获整个数据库级 DDL 删除（如 DROP TABLE） - 启用后，日志不是实时刷盘，默认有最多 1 秒延迟；若设
QUEUE_DELAY = 0，会显著增加 I/O 压力，线上慎调
MySQL 的 binlog 不含用户名，纯靠它无法锁定操作者
即使 @@log_bin = 1 且 @@binlog_format = 'ROW'，mysqlbinlog 解析出的也只是 ### DELETE FROM `db`.`users` WHERE @1=123 这类语句，没有 user@host 字段。想补全“谁删的”，只能组合其他日志：
- 开启
general_log并设为表存储（general_log_file+general_log = ON），再关联同一时间戳的Connect和Query事件，但该日志会拖慢高并发写入，仅建议临时开启数分钟 - 部署 MySQL 审计插件（如
audit_log），它会在每条语句前记录user: root@10.0.1.5，但需在my.cnf加plugin-load = audit_log.so并重启，动态加载不可行 - 云数据库（如阿里云 RDS、腾讯云 CDB）要进控制台单独开启“SQL 审计”，默认关闭且保留期通常仅 7 天，过期即不可查
PostgreSQL pg_audit 扩展需手动启用 delete 操作且不记行内容
pg_audit 不是装完就自动审计 DELETE。它默认只记录 DDL 和 session 级操作，要追踪某张表的删除，必须三步走：CREATE EXTENSION pg_audit → 设 pgaudit.log = 'write' → 再加 pgaudit.log_relation = on。即便如此，日志里也只有 DELETE FROM users WHERE id = $1，参数值和被删行的完整字段全无。
- 想拿到真实数据，得配合触发器 + 自定义日志表，用
SELECT row_to_json(OLD)把整行转 JSON 存进去，但会影响主表 DELETE 性能 -
log_statement = 'all'是备选方案，但它把所有语句当字符串记，WHERE 条件一律变成问号，DELETE FROM users WHERE id = 123只会记成DELETE FROM users WHERE id = ? - 日志输出到 PostgreSQL 服务器日志文件（由
log_destination控制），不是数据库表，查时得用grep -A5 "DELETE" /var/log/postgresql/*.log配合时间筛选
触发器是跨数据库最可控的审计手段，但要注意事务一致性
在目标表上建 AFTER DELETE 触发器，把 deleted 伪表内容和 SUSER_SNAME()（SQL Server）、CURRENT_USER（PostgreSQL）、USER()（MySQL）一起写入审计表，这是唯一能 100% 确保“删一行、记一行”的方式。但它有个硬约束：触发器和主 DELETE 在同一事务内，若审计表写入失败（如磁盘满、字段超长），整个删除会回滚。
- MySQL 触发器里不能用
SELECT ... INTO赋值给变量，得用SET var = (SELECT ...)，否则语法报错 - SQL Server 触发器中
deleted表可能含多行，必须用INSERT INTO audit_log SELECT *, GETDATE() FROM deleted批量插入，不能用循环 - PostgreSQL 触发器函数返回类型必须是
TRIGGER，且最后一行必须是RETURN OLD或RETURN NULL，否则触发器不生效
真正麻烦的从来不是“怎么查”，而是“查的时候发现什么都没开”。审计能力必须在数据出事前就验证过——比如删一条测试记录，立刻去查审计日志是否出现对应条目。等真丢了核心数据再补，大概率只剩备份可用了。
