在业务系统里，用户点或运营人员点一下“删除”，背后如果直接执行MySQL的DELETE语句，这条记录就物理消失了。一旦误删或者后续需要追溯历史，只能依赖备份。软删除的核心思路是：不真正删数据，而是打一个标记，查询时自动过滤掉被标记的行，从而实现逻辑上的删除。
一、软删除的基本表结构设计
最常见的做法是在业务表中增加一个标记字段。一般有两种选型：用tinyint类型的is_deleted表示是否删除，或者用datetime类型的deleted_at记录删除时间。前者占用空间小、语义简单；后者能天然保留删除时间点，方便做数据恢复和清理策略。
下面是一张用户表的示例，采用deleted_at方案：
CREATE TABLE `user` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL, `email` VARCHAR(100) NOT NULL, `deleted_at` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_email` (`email`, `deleted_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
注意上面的唯一索引把deleted_at也拼进去了。如果只用email做唯一键，那么同一个邮箱在软删除后不能再注册，因为旧记录还占着唯一位。把deleted_at纳入联合唯一索引，未删除时其值为NULL，MySQL中NULL不等于NULL，因此允许多个“已删除”的同邮箱存在，而正常行依然保持邮箱唯一。
二、查询与删除的SQL规范
所有业务查询都必须带上“未删除”条件。如果项目里散落着大量SELECT * FROM user，很容易把已删除数据捞出来。建议在数据访问层统一追加过滤条件，或者利用视图来封装。
软删除执行时，不再是DELETE，而是UPDATE：
-- 软删除一条用户 UPDATE `user` SET `deleted_at` = NOW() WHERE `id` = 123 AND `deleted_at` IS NULL; -- 查询有效用户 SELECT `id`, `username`, `email` FROM `user` WHERE `deleted_at` IS NULL ORDER BY `id` DESC LIMIT 20;
这种写法在单表场景很清晰。但在联表查询时，每个被关联的表都要加deleted_at IS NULL，否则JOIN可能把已删除的父级或子级带出来，造成脏数据。团队规范里应当明确要求：任何JOIN语句中涉及的业务表，都必须在ON或WHERE里声明软删除过滤。
三、数据恢复与物理清理
软删除最大的好处是数据可恢复。运营误删了某条内容，只需要把deleted_at置回NULL即可，不需要从binlog或备份里抠数据。
-- 恢复被软删除的用户 UPDATE `user` SET `deleted_at` = NULL WHERE `id` = 123;
但软删除不是免死金牌。时间一长，表里堆满“已删除”行，会影响索引效率和备份体积。项目规范里应定义清理任务：比如保留删除记录90天，之后由定时脚本物理删除。清理脚本要分批进行，避免长事务锁表。
-- 每次清理1000条早于90天的已删除数据 DELETE FROM `user` WHERE `deleted_at` IS NOT NULL AND `deleted_at` < DATE_SUB(NOW(), INTERVAL 90 DAY) LIMIT 1000;
这个清理动作最好在业务低峰期跑，并且监控受影响行数。若一次清理量太大，可以循环执行直到无符合条件记录。对于含有外键关联的表，要先清理子表再清理父表，或暂时关闭外键检查，但需评估风险。
四、ORM与项目落地注意点
如果使用MyBatis、Hibernate或GORM等框架，应优先使用其自带的软删除支持，而不是手写SQL漏掉条件。例如在GORM里给模型加gorm.DeletedAt字段，框架会自动过滤和赋值。
另外要警惕唯一索引与软删除配合的坑：前文提到的联合唯一索引方案虽然解决了重复注册，但在恢复数据时要注意，如果曾经存在多个同邮箱的已删除记录，恢复其中一条后，它的deleted_at变成NULL，可能和另一条未删除记录冲突。因此恢复前应先确认该邮箱当前没有有效记录。
type User struct {
ID uint
Username string
Email string
DeletedAt gorm.DeletedAt // 软删除字段
}
// 自动软删除
db.Delete(&user, 123)
// 自动过滤已删除
db.Where("username = ?", "tom").Find(&users)
最后，团队内部要形成文档规范：建表评审时检查是否有软删除需求、字段命名统一为deleted_at或is_deleted、所有数据访问封装层默认带过滤、禁止业务代码直接拼写物理DELETE。这样MySQL里的数据既干净又可追溯。