嵌套查询无法恢复物理删除的数据，因为delete后原始数据已从表中消失；它只能基于现存数据（如审计日志）进行关联或推导，前提是删除前的上下文信息仍保留在数据库中。
不能直接还原被物理删除的数据关系——DELETE 之后数据已从表中消失，嵌套查询本身不具备“找回已删行”的能力。它只能在现存数据中做关联、筛选或推导，前提是删除前的上下文信息仍以某种形式保留在库中（比如审计日志、历史快照、冗余状态字段）。
为什么 EXISTS / IN 无法恢复物理删除的数据
常见误解是：用 EXISTS 或 IN 子查询“查出被删记录的痕迹”，就能反向重建关系。但实际执行时：
-
EXISTS (SELECT 1 FROM audit_log WHERE record_id = users.id AND action = 'DELETE')只能告诉你“这个用户曾被删”，不能还原users表里那行原始数据 - 如果
users表已被DELETE，主表无记录，任何对它的JOIN或子查询都返回空——嵌套查询没东西可查 - 子查询再深、条件再复杂，也改变不了“源数据不存在”这个事实
真正可行的嵌套查询场景：依赖审计日志重建逻辑视图
只有当审计日志（如 audit_log）完整记录了操作前后的关键字段，且你接受“非原始表结构”的还原结果，嵌套查询才有用。典型做法是把日志当“只读快照”用：
- 用
SELECT DISTINCT record_id FROM audit_log WHERE action = 'DELETE'找出所有被删主键 - 对每个
record_id，用子查询拉取最后一次INSERT或UPDATE的完整字段：SELECT a1.record_id, (SELECT a2.field1 FROM audit_log a2 WHERE a2.record_id = a1.record_id AND a2.action IN ('INSERT', 'UPDATE') ORDER BY a2.created_at DESC LIMIT 1) AS field1, (SELECT a2.field2 FROM audit_log a2 WHERE a2.record_id = a1.record_id AND a2.action IN ('INSERT', 'UPDATE') ORDER BY a2.created_at DESC LIMIT 1) AS field2 FROM audit_log a1 WHERE a1.action = 'DELETE' GROUP BY a1.record_id; - 注意：每个字段单独子查询效率低，大数据量建议改用
ROW_NUMBER() OVER (PARTITION BY record_id ORDER BY created_at DESC)配合 CTE 提前过滤
嵌套查询容易踩的坑：时序错乱与字段缺失
审计日志不是数据库备份，字段覆盖和时间精度决定还原质量：
- 漏掉
ORDER BY created_at DESC LIMIT 1就可能取到旧值而非最后状态——audit_log里同一record_id可能有十几条UPDATE，不排序默认取第一条 - 日志表没存全字段？比如
INSERT记了name和email，但后续UPDATE只记了email，那name字段在子查询里就会是NULL - 时钟不同步导致
created_at乱序？得加ABS(TIMESTAMPDIFF(SECOND, a2.created_at, a1.created_at)) 宽容窗口，否则 <code>DELETE前 5 分钟的UPDATE可能被排除 -
audit_log本身也被清理过？查MAX(created_at)确认日志保留周期是否覆盖误删时间点
嵌套查询能做的极限，就是从残留痕迹里拼凑出近似状态；真要还原原始数据行，必须依赖 binlog、WAL 或备份——而这些根本不是 SQL 查询能驱动的。最容易被忽略的一点：很多人花半天写嵌套子查询，却没确认审计日志里到底有没有存 user_role_id 这种外键字段，结果还原出来的“关系”全是空值。
