【数据存储】误删找回：软删除设计与恢复流程

实战应用：用在哪里

误删是运维的必修劫：一条手滑的 DELETE 让玩家的裁决之杖凭空消失，找回的过程比备份还原更快才有救赎。软删除设计让删除变成标记，恢复变成改标记，误操作的代价从灾难降级成一次工单。

软删除的实施

---删除即标记：deleted_at 置时间戳
function SoftRepo.delete(table, id, operator)
    DB.exec(
        "UPDATE ?? SET deleted_at = ?, deleted_by = ? WHERE id = ? AND deleted_at = 0",
        table, os.time(), operator, id)
    Audit.log("soft_delete", table, id, operator)
end

---业务查询默认过滤已删行
function SoftRepo.find(table, id)
    return DB.queryRow(
        "SELECT * FROM ?? WHERE id = ? AND deleted_at = 0", table, id)
end

删除不再执行 DELETE，改为 deleted_at 写时间戳、deleted_by 写操作人，业务查询统一带 deleted_at = 0 的过滤。行还在原位意味着恢复只是把时间戳清零，撤销的成本从小时级降到秒级。审计记录删除的四元组：谁、何时、删了什么表、哪一行——误删的追溯与恢复在同一份记录上完成。

恢复的流程

---恢复：清标记加关联数据校验
setontimerex(58, 300)
function SoftRepo.restore(id, table, operator)
    local row = DB.queryRow(
        "SELECT * FROM ?? WHERE id = ?", table, id)
    if not row or row.deleted_at == 0 then
        return false, "行不存在或未删除"
    end
    DB.exec("UPDATE ?? SET deleted_at = 0 WHERE id = ?", table, id)
    Audit.log("restore", table, id, operator)
    return true
end

恢复的入口先验行状态：存在且已删才允许恢复，恢复动作同样留审计。物理删除的兜底留给定期任务：软删超过 180 天的行才转物理归档，窗口期内一切误删可救。恢复的关联校验：恢复一件装备前确认其持有者账号未注销，恢复到悬空引用会制造新的问题。回收站的查询界面给客服用：按玩家查最近 30 天的软删记录，一眼定位误删的行。

验证与监控

软删与恢复的操作量日监控，恢复量的突增提示误操作的系统性原因；180 天物理归档的行数核对，归档后的行在软删查询中永久消失。

踩坑记录

业务查询曾经漏带 deleted_at 过滤，已删物品出现在交易行，过滤统一下沉到仓储层。恢复曾经不查持有者状态，装备恢复到一个已注销的账号上悬空，关联校验补上。软删的表膨胀拖慢查询，deleted_at 的部分索引让热查询不受冷数据拖累。

上线要点

软删除覆盖的表清单由数据评审确定：物品、邮件、行会为必覆盖，日志类不走软删。恢复的权限收敛到主管级，恢复操作双人复核。物理归档的执行窗口放低峰期，归档批次的大小以 IO 水位为准。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。