MySQL不支持原生软删除，需通过is_deleted或deleted_at字段实现；建表/加字段、统一查询过滤、改DELETE为UPDATE、配套归档与恢复机制是关键。
MySQL本身不提供原生的“软删除”功能，软删除本质是通过字段标记代替物理删除，关键在于设计、查询和维护的一致性。
添加删除标记字段
在需要软删除的表中增加一个布尔型或时间戳类型的字段，推荐使用 is_deleted TINYINT(1) DEFAULT 0 或 deleted_at DATETIME NULL。前者语义清晰、索引效率高；后者可记录删除时间，便于审计与恢复。
- 建表时直接添加：is_deleted TINYINT(1) NOT NULL DEFAULT 0
- 已有表可在线添加：ALTER TABLE user ADD COLUMN is_deleted TINYINT(1) DEFAULT 0 AFTER id;
- 为提升查询性能，对 is_deleted 字段建立索引（尤其当该字段选择性高时）
统一查询过滤逻辑
所有业务查询必须默认排除已删除数据，避免手动漏写 WHERE is_deleted = 0。推荐方式：
- 应用层封装：在DAO/Repository层统一拼接 AND is_deleted = 0 条件
- 视图替代基表：创建 v_user 视图仅暴露未删除记录，业务代码查视图而非原表
- MySQL 8.0+ 可用生成列 + 唯一约束辅助（如需保证未删除状态下的字段唯一性）
重写删除操作为更新
将 DELETE FROM user WHERE id = 123 替换为安全的逻辑删除语句：
- 基础软删：UPDATE user SET is_deleted = 1 WHERE id = 123 AND is_deleted = 0;（加条件防止重复操作）
- 带时间戳软删：UPDATE user SET deleted_at = NOW() WHERE id = 123 AND deleted_at IS NULL;
- 必要时配合事务与影响行数校验，确保删除成功或提示“记录不存在/已被删除”
清理与恢复机制不可少
软删除不是永久保留，需配套策略避免数据膨胀和逻辑混乱：
- 定期归档：将 is_deleted = 1 且超过N个月的数据导出并物理删除
- 后台恢复接口：提供 UPDATE ... SET is_deleted = 0 支持误删回滚（注意检查业务约束是否仍满足）
- 统计类报表应明确区分“有效数据”与“已删除数据”，避免指标失真
