软删除本质是逻辑标记而非物理移除，通过 is_deleted 字段实现，需统一过滤查询、防止外键断裂、处理唯一索引与分页问题，并定期归档清理。
为什么 不能直接用 DELETE 语句删数据
软删除本质是「逻辑标记」而非物理移除，核心目的是保留历史关联、审计线索和避免外键级联断裂。一旦执行 DELETE FROM user WHERE id = 123，数据彻底丢失，恢复只能靠备份——而备份往往滞后、不全、恢复成本高。更麻烦的是，如果 order 表里有 user_id = 123 的记录，硬删后它就变成悬空外键，业务查用户订单时可能报错或漏数据。
所以规范要求：所有主业务表必须支持软删除，且默认禁止执行裸 DELETE（可通过 MySQL 的 sql_safe_updates=1 或应用层拦截）。
用 is_deleted 字段 + 默认值实现最简软删除
推荐在每张需软删除的表中添加 is_deleted TINYINT(1) DEFAULT 0 NOT NULL 字段（不用 ENUM 或 VARCHAR，避免索引失效和类型转换开销）。注意不是 deleted_at 时间戳字段——后者虽能记录删除时间，但查询时要判 IS NULL，MySQL 对 IS NULL 的索引利用不如等值查询稳定，且新增字段占用更多空间。
-
is_deleted = 0表示正常数据（显式写，不依赖默认值做业务判断） - 所有
SELECT必须加WHERE is_deleted = 0，建议封装到 DAO 层或视图中统一过滤 - 更新时用
UPDATE user SET is_deleted = 1 WHERE id = 123 AND is_deleted = 0，防止重复删除或误删已删数据 - 给
is_deleted单独建索引意义不大，应与高频查询字段组合，例如INDEX idx_status_uid (is_deleted, user_id)
真实项目中容易被忽略的三个坑
软删除不是加个字段就完事。下面这些点没处理好，上线后会出隐蔽 bug：
- 外键约束不会自动识别
is_deleted，ON DELETE CASCADE依然会物理级联删子表——必须改用逻辑级联：在应用层或存储过程中先查出待删主记录的子记录 ID 列表，再批量更新它们的is_deleted - 唯一索引（如
UNIQUE KEY uk_mobile (mobile)）对已软删的数据仍生效，导致“重用手机号注册失败”。解决方式是把唯一索引改成带条件的函数索引（MySQL 8.0.13+）：CREATE UNIQUE INDEX uk_mobile_active ON user (mobile) WHERE is_deleted = 0 - 分页查询时，
ORDER BY created_at DESC LIMIT 20会把软删数据也计入偏移量，造成“翻页跳数据”。必须在WHERE中强制过滤，并确保排序字段和is_deleted一起参与索引，例如INDEX idx_del_created (is_deleted, created_at)
如何安全地清理真正过期的软删数据
软删不是永久存档。长期积累的 is_deleted = 1 数据会拖慢查询、增大备份体积、干扰统计口径。必须定期归档并物理清理，但绝不能简单 DELETE FROM user WHERE is_deleted = 1。
正确做法分三步走：
START TRANSACTION; -- 1. 先查出要清理的 ID（加 LIMIT 防锁表太久）SELECT id INTO @batch_ids FROM user WHERE is_deleted = 1 ORDER BY id ASC LIMIT 10000; -- 2. 把这批 ID 插入归档表（归档表结构相同，但无业务索引）INSERT INTO user_archive SELECT * FROM user WHERE id IN (@batch_ids); -- 3. 物理删除（WHERE 条件必须包含主键，避免全表扫描）DELETE FROM user WHERE id IN (@batch_ids) AND is_deleted = 1; COMMIT;重点：归档操作必须在事务内完成，且每次清理量严格限制（如 1w 行），否则会长时间锁表；生产环境清理必须避开高峰，并监控 innodb_row_lock_time_avg 指标。
