如何用mysql实现数据软删除_mysql项目规范讲解

来源：这里教程网时间：2026-02-28 20:35:59 作者：

为什么不能直接用 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 行），否则会长时间锁表；生产环境清理必须避开高峰，并监控