系统程序开发，数据删除该用物理删还是逻辑删？

数据删除没有标准答案。按2026年项目交付习惯，逻辑删除（加 is_deleted 标记）优先用于需要审计、可恢复、反查历史的核心业务表；物理删除（直接删掉记录）只适合临时数据、缓存和日志。判断依据是四个维度：回溯需求、合规要求、查询负担和存储成本。

先说结论：核心业务默认逻辑删除，临时数据才物理删除

逻辑删除是在表里加一个删除标记（常见字段 is_deleted），查询时自动过滤；物理删除是把 record 直接从表里 DELETE。2026 年常见做法是：订单、用户、合同、支付流水等核心数据优先采用逻辑删除；操作日志、临时表、同步缓存等可抗性数据用物理删除。

这样划分的原因是，一旦物理删掉核心数据，恢复成本和业务风险太高。经验区间是：只要数据有可能被二次核对，就按逻辑删除设计。

• 需要审计、可恢复的业务表 → 逻辑删除
• 临时数据、日志、缓存 → 物理删除

为什么删数据方式常常导致返工

交付现场常见的一种情况是：开发阶段为省事用物理删除，到了测试或上线后，甲方提出报表要还原已删除订单，或者审计要查历史操作，只能再补逻辑删除字段，改造接口、同步存量数据，周期至少多出一周。所以删除策略不是小细节，它决定系统后续能不能对上账。

有个项目，排期只有三周，预算也卡得紧，甲方在验收前突然要求能恢复误删的订单，我们不得不中途加逻辑删除字段，改接口、补数据，最后延误两天上线。按犀跃公司的交付习惯，需求评审阶段就会把删除策略列为评审项。

• 返工集中在接口改造和存量数据梳理
• 联调后改策略影响关联模块

四维判断法：判断该用物理删除还是逻辑删除

我习惯用四个维度去卡，每个维度单独过一遍，只要有两个以上踩中“必须回溯”，就用逻辑删除。

• 回溯需求：删除后是否还有可能被业务方或用户要求找回来？如果是，逻辑删除。
• 合规审计：是否涉及资金、合同、实名信息？涉及，逻辑删除，且最好保留操作日志。
• 查询与统计：逻辑删除会让每个查询都带 is_deleted = 0 条件，写漏一个就出现数据偏差；物理删除则没有这个负担。
• 存储与性能：逻辑删除的数据会一直留在表里，表越来越大，索引膨胀；物理删除能释放空间，但不可逆。经验区间是，超过几千万行的大表，纯逻辑删除要配合定期归档。

注意，四维判断不是打分题，是条件筛。只要前两条有任一命中，就应该用逻辑删除；只有前两条都不满足，才去考虑物理删除。

物理删除 vs 逻辑删除：方案对比

把两种方式放在一起看，它们各自的代价和收益差距明显。

• 物理删除：直接 DELETE，简单直接，查询快，空间释放；缺点是不可恢复，没有留痕，误操作就永远没了。
• 逻辑删除：UPDATE 设置 is_deleted = 1，数据保留，可恢复，可审计；缺点是查询要带条件，唯一索引容易失效，还要定期清理归档。

适用的典型场景，物理删除适合：临时表、缓存表、一次性任务生成的中间数据；逻辑删除适合：订单、用户、库存、财务流水。按实际交付经验，多数业务核心表都会用逻辑删除，但会配一个定时清理任务，将超过保留期（比如 90 天）的历史数据物理清除。

常见坑：逻辑删除不是“加个字段”那么简单

逻辑删除看似简单，实际埋了很多雷。下面三个坑是项目里最常见的。

• 唯一索引失效：比如用户手机号有唯一约束，逻辑删除后再次注册，同手机号还是会在唯一索引里冲突。解决方法是把 is_deleted 并入唯一索引，或用删除时间戳做部分唯一索引。
• 漏加过滤条件：写统计 SQL 时忘了 where is_deleted = 0，报表数据直接不对。
• 从不清理：逻辑删除只增不减，表数据无限膨胀，性能下滑。建议按业务周期定期归档或清理。

在项目里，这些坑几乎每个都会遇到至少一次。提前跟甲方约定清理周期和归档策略，比事后补更省成本。

适用场景与边界

适合用逻辑删除的情况：业务数据需要审计、存在多系统对账、用户可申请注销后恢复账号，以及任何“删除后还要留证据”的场景。适合用物理删除的情况：纯临时数据、日志、缓存、无价值的中间结果，明确不需要保留。

不适合强行逻辑删除的情况：高频写入且数据量极大的埋点日志，逻辑删除会被存储压垮；或者内存数据库中的临时键，物理删除更合理。边界要提前说清楚，避免“所有表都加 is_deleted”。

• 适合逻辑删除：有审计、对账、恢复诉求的业务核心表
• 不适合逻辑删除：超大日志、埋点、临时缓存

常见问题

物理删除后数据还能找回吗？

通常不能。如果不提前做备份或 binlog 回放，物理删除后找回难度大，且不一定能按时间点还原，所以核心业务别赌这个。

逻辑删除的字段需要加索引吗？

建议建。如果查询经常带 is_deleted = 0 条件，单独索引或复合索引都能减少扫描范围。但要注意过滤性，若绝大多数数据未删除，索引帮助有限。

逻辑删除和回收站是一回事吗？

不是。回收站是应用层面的用户功能，逻辑删除是数据层的软标记。可以配合实现，但逻辑删除更底层，主要面向审计与数据恢复。

什么数据一定不要用逻辑删除？

临时表、重算缓存、批量任务的中间结果，删了就删了，没必要保留。还有超大日志表，物理删除或分区清理更合适。

如果系统一开始用了物理删除，后期怎么改逻辑删除？

常见做法是新增 is_deleted 字段，默认 0，把原来的删除接口改为 UPDATE，并写数据订正脚本恢复已删除记录（如果有 binlog）。改动量取决于接口数量，经验区间是中等规模系统要 3-7 天。

行动建议：先按四维判断法过一遍你的核心表，把删除策略写成字段注释；再约定逻辑删除数据的保留周期和清理任务。如果项目已经在用物理删除，尽快评估风险并做改造计划。这个决策不复杂，但定了就别随意改，否则返工成本会成倍增加。