如何排查SQL数据库的异常数据删除_查看数据库操作审计日志

不是必须开 general_log，但它是直接“操作录像”；没开时 binlog（需 ROW 格式）是唯一能还原真实 SQL 的来源；云数据库需通过平台审计功能开启，且默认不启用、保留时间短。MySQL 没开 general_log 就没法查谁删了数据？不是必须开 general_log，但它是最直接的“操作录像”。没开的话，binlog 是唯一能还原真实 SQL 的来源——前提是开启了 binlog_format = ROW 且保留时间够长。general_log 记所有语句但性能损耗大，生产环境通常关着；binlog 默认只记逻辑变更（STATEMENT 格式），遇到 NOW()、UUID() 等函数就无法精确还原原始语句。binlog 必须启用：log_bin = ON，且 binlog_format = ROW 才能看见被删的每一行内容SHOW VARIABLES LIKE 'log_bin'; 和 SHOW VARIABLES LIKE 'binlog_format'; 先确认这两项如果用的是 STATEMENT 或 MIXED，DELETE FROM t WHERE id=123 能看到，但 DELETE FROM t WHERE updated_at 只会记成“执行了一条 DELETE”，删了哪些行完全不可知用 mysqlbinlog 解析出具体删除行为mysqlbinlog 是唯一能从 binlog 文件里提取原始操作的命令。它不连接数据库，而是读取磁盘上的 .000001 类文件，所以得先找到对应时间段的 binlog 文件名。查当前活跃 binlog：SHOW MASTER LOGS;，再结合 SHOW BINLOG EVENTS IN 'mysql-bin.000005' LIMIT 20; 快速定位时间范围导出可读 SQL：mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000005 > out.sql，注意必须加 --base64-output=DECODE-ROWS -v，否则看不到 ROW 模式下的具体行数据输出里找 ### DELETE FROM `db`.`table` 开头的块，每块下面的 ### @1=123 就是被删行的主键值别直接在生产库上运行 mysqlbinlog —— 它会读锁 binlog 文件，高并发下可能卡住写入PostgreSQL 怎么查谁删了数据？PostgreSQL 没有内置类似 MySQL 的 row-level binlog，审计靠扩展或日志配置。最可靠的是开启 pg_audit 扩展，其次才是解析 CSV 格式的 log_statement = 'all' 日志——但后者只记语句模板，不记参数值，DELETE 语句里的 WHERE 条件全变成问号。 RedClaw 百度推出的手机端万能AI Agent助手