软删除是应用层与表结构协同的设计约定，需用TINYINT(1)/BOOLEAN类型、NOT NULL DEFAULT 0的is_deleted字段，配合WHERE is_deleted = 0查询、带条件UPDATE及合理索引。
软删除不是数据库功能，而是应用层与表结构协同的设计约定；直接用 DELETE 语句就破功了，所有后续问题都源于此。
deleted 字段该用什么类型和默认值
必须用 TINYINT(1) 或 BOOLEAN（MySQL 里二者等价），别用 VARCHAR、ENUM 或 BIT。整型判断快、索引高效、ORM 映射不翻车。
- 字段名统一用
is_deleted或deleted，避免status这类歧义词 - 定义时加
NOT NULL DEFAULT 0——DEFAULT NULL是坑，会导致查询必须写WHERE is_deleted = 0 OR is_deleted IS NULL，漏一个条件就查出脏数据 - 如果需要审计，额外加
deleted_at DATETIME NULL字段，但主状态仍以is_deleted为准
UPDATE 语句怎么写才不会误删或漏改
软删除本质是带条件的 UPDATE，不是无脑设值。重复执行同一语句不该有副作用，也不能跳过已删记录。
- 错误写法：
UPDATE user SET is_deleted = 1 WHERE id = 123—— 第二次执行时，已删记录照样被更新，影响行数为 0，但你感知不到 - 正确写法：
UPDATE user SET is_deleted = 1 WHERE id = 123 AND is_deleted = 0—— 确保只改未删数据，影响行数可作成功判断依据 - 批量操作前建议先
SELECT id FROM user WHERE id IN (123,456) AND is_deleted = 0，确认目标存在且未删，再执行UPDATE - 别在事务外单独执行软删，尤其涉及多表关联时；中间失败会导致状态不一致
查询时为什么总漏掉 WHERE is_deleted = 0
90% 的软删除 Bug 都发生在这里：开发写 SQL 时忘了加过滤条件，导致前端看到“已删除”数据，或统计总数虚高。
-
SELECT *、COUNT(*)、JOIN全得显式加WHERE is_deleted = 0，不能靠 ORM 自动补（除非你确认框架已全局启用） -
LEFT JOIN时，右表也要限制：LEFT JOIN order ON u.id = order.user_id AND order.is_deleted = 0，否则会关联出已删订单 - 后台导出、报表 SQL、定时任务脚本最容易漏条件，这些地方要重点 review
- Laravel 的
withTrashed()、MyBatis-Plus 的queryWrapper.eq("is_deleted", 0)都得手动写，没银弹
is_deleted 字段要不要建索引
要，但不是无脑加。不建索引时，每次 WHERE is_deleted = 0 都全表扫描，数据一过百万就卡死。
- 单列索引足够：
ALTER TABLE user ADD INDEX idx_is_deleted (is_deleted) - 如果高频查询还带其他条件（比如按状态+时间分页），考虑联合索引：
ALTER TABLE user ADD INDEX idx_is_deleted_status_created (is_deleted, status, created_at) - 注意选择性：如果表里 95% 数据都是
is_deleted = 1，那is_deleted = 0是低区分度条件，索引效果有限，得看EXPLAIN结果再决定 - 唯一约束受影响时（如用户名唯一），必须改成联合索引：
ALTER TABLE user ADD UNIQUE INDEX uk_username_deleted (username, is_deleted)，否则删完再注册同名用户会报错
最易被忽略的是：软删除后，COUNT(*) 和 ORDER BY 行为会变，而开发者常默认它们“应该一样”。实际得重写逻辑、重建索引、校验执行计划——不是加个字段就完事。
