软删除场景下主键还能唯一标识记录吗？

Question

在软删除场景中，记录未被物理删除，仅通过标记（如 `is_deleted` 字段）表示删除状态。此时主键是否仍能唯一标识一条记录？常见问题是：当同一业务实体被反复创建与软删除时，数据库中可能出现多个“同主键业务字段”但不同删除状态的记录，若主键设计不合理（如使用自然键而非代理键），可能导致主键冲突或查询歧义。因此，尽管主键在数据库层面仍保持唯一性，但在业务语义上是否“有效唯一”值得考量。如何设计主键策略，确保软删除后可重复创建且不破坏唯一性约束？

Answer 1

一、软删除场景下的主键唯一性挑战

在数据库设计中，软删除是一种常见的数据管理策略，通过添加一个标志字段（如 is_deleted）来标记记录是否被“逻辑删除”，而非真正从存储中移除。这种方式保留了历史数据，便于审计与恢复，但也带来了主键语义上的复杂性。

数据库层面的主键约束保证了每条记录的物理唯一性，但当使用自然键作为主键时（例如用户邮箱、订单编号等），若允许同一业务实体被反复创建与软删除，则可能出现多个同名业务字段但不同删除状态的记录。这导致虽然主键仍满足数据库唯一性要求，但在业务语义上失去了“有效唯一”的意义。

例如：用户注册邮箱为 [e-mail]，注销后软删除；再次注册时若系统不允许重复邮箱，则无法插入；若允许，则可能产生两条相同邮箱但 is_deleted=1 和 0 的记录，引发查询歧义。

1.1 常见问题表现形式

• 主键冲突：自然键作为主键时，无法重复插入已软删除的实体。
• 业务查询歧义：查询“当前有效用户”时需额外过滤 is_deleted = 0，否则结果包含无效数据。
• 索引效率下降：频繁软删除导致表中大量“僵尸数据”，影响查询性能。
• 外键引用混乱：其他表引用已被软删除的记录，造成语义不清。
• 数据一致性风险：级联操作难以处理软删除状态。
• 审计追踪困难：缺乏时间维度信息，难以判断生命周期。
• 唯一约束失效：基于业务字段的唯一索引未考虑删除状态。
• API 行为不一致：前端认为“删除即消失”，后端仍保留数据。
• 批量导入失败：因历史软删除记录阻塞新数据写入。
• 多租户环境下隔离问题：不同租户误共享软删除资源。

二、主键设计策略分析

为解决上述问题，必须重新审视主键的设计原则。核心在于区分“数据库唯一性”与“业务有效性”。以下是几种主流策略：

策略类型	主键方式	优点	缺点	适用场景
代理主键 + 软删除	自增ID或UUID	避免自然键冲突，支持重复创建	业务字段需单独加唯一约束控制	通用型系统，如CRM、ERP
复合主键（ID + is_deleted）	(id, is_deleted)	理论上允许多版本共存	破坏主键稳定性，外键关联复杂	极少使用，不推荐
业务键 + 删除状态联合唯一索引	UNIQUE (email, is_deleted)	确保同一状态下业务键唯一	需应用层配合处理状态转换	高合规性要求系统
时间戳增强自然键	email + deleted_at	支持历史版本追溯	增加查询复杂度	审计密集型系统
独立归档表结构	拆分 active / archive 表	彻底分离状态，提升查询效率	增加维护成本和同步逻辑	大数据量高频删改场景

2.1 推荐方案：代理主键 + 业务字段唯一约束增强

采用代理主键（如 BIGINT AUTO_INCREMENT 或 UUID）作为表的主键，同时对关键业务字段（如用户名、手机号、订单号）建立条件唯一索引，仅对未删除记录生效。以 MySQL 为例：

-- 使用表达式索引（MySQL 8.0+）
CREATE UNIQUE INDEX uk_user_email_active 
ON users(email) 
WHERE is_deleted = 0;

-- PostgreSQL 可使用部分索引
CREATE UNIQUE INDEX uk_user_email_active 
ON users(email) 
WHERE is_deleted = false;

该设计保障了：

• 主键始终唯一且稳定，不受删除状态影响；
• 业务字段在“有效状态”下保持唯一性；
• 允许同一业务实体在软删除后重新创建；
• 查询当前有效数据时可通过索引高效定位。

三、架构演进与流程设计

为了系统化应对软删除带来的主键语义漂移问题，建议引入领域驱动设计（DDD）中的“聚合根”概念，并结合事件溯源模式进行扩展。以下是一个典型的数据写入与查询流程：

graph TD
    A[客户端请求创建用户] --> B{检查是否存在未删除用户}
    B -- 存在 --> C[返回错误: 用户已存在]
    B -- 不存在 --> D[插入新记录 with is_deleted=0]
    D --> E[发布 UserCreatedEvent]
    
    F[客户端请求删除用户] --> G[更新 is_deleted=1]
    G --> H[发布 UserDeletedEvent]
    
    I[查询活跃用户] --> J[SELECT * FROM users WHERE is_deleted=0 AND ...]
    
    K[定时任务归档] --> L[将 is_deleted=1 且超过N天的记录迁移到 history_users 表]
    

3.1 数据库层设计规范

制定统一的数据表结构模板，强制实施最佳实践：

CREATE TABLE users (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    email VARCHAR(255) NOT NULL,
    name VARCHAR(100),
    is_deleted BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    deleted_at TIMESTAMP NULL DEFAULT NULL,
    
    -- 关键：仅对未删除状态 enforce 唯一性
    CONSTRAINT uk_user_email_active 
        UNIQUE (email) WHERE (is_deleted = 0)
);

配合触发器或应用服务层逻辑，在更新 is_deleted 字段时自动设置 deleted_at 时间戳，便于后续清理与分析。

3.2 应用层协同控制

在 ORM 层封装软删除行为，例如使用 Laravel 的 SoftDeletes trait 或 Hibernate 的 @Where 注解，自动为所有查询附加 is_deleted = 0 条件，防止“脏读”。

同时，在创建逻辑中显式检查目标业务键是否已在有效状态下存在，避免依赖数据库报错进行流程控制，提升用户体验与系统健壮性。