报错是这么冒出来的。知识库里有 30 份产品文档被误删，平台只能看到「文档已删除」，查不到是谁在什么时间删的；操作日志表里只有登录记录，恢复时无法确认影响范围，数据库是 MySQL 8.0。
中间走过弯路，把「没有记录请求 id 与操作者 id」当成主因，改完现象没变。
原因不止一个，得分开看。删除操作没写审计表，只打了应用日志。少数情况下是应用日志按天切割，7 天后被清理。
不容易想到的是，软删除字段被物理删除覆盖，恢复不了。
上来先确认审计表里有没有删除记录
mysql -e "select count(*) from audit_log where action='doc.delete'"随后打开软删除并记录操作者
python -c "print('UPDATE docs SET deleted_at=NOW(), deleted_by=%s WHERE id=%s')"接着在删除接口补写审计事件
python -c "print({'action':'doc.delete','actor':user_id,'target':doc_id,'ts':now})"剩下的就是按时间范围反查误删的文档
mysql -e "select id,title,deleted_by from docs where deleted_at >= '2026-11-01'"怎么算真的好了，看的是同一批现象。审计表里能看到每条删除的操作者、时间和目标 id，误删的 30 份文档能按记录恢复，日志保留期覆盖 90 天。
这里还有个坑。审计日志要独立于应用日志保存，并且只追加不修改；只做软删除能救一次误操作，但没有操作者记录仍然定位不到人。报错文案容易误导，真正的原因往往在相邻那一层的日志里。