软删除应优先用 UPDATE 设置 deleted_at 和 status 字段而非 DELETE，需统一字段命名、添加联合索引、避免函数操作、分页批量执行并同步更新所有读取逻辑。
WHERE 子句里不能直接写 OR 逻辑来切换删除条件
很多人想用 DELETE FROM orders WHERE status = 'pending' OR user_id IN (SELECT id FROM users WHERE is_blocked = true) 这种写法实现“满足任一条件就删”，但实际执行时可能误删——比如 user_id 为 NULL 的记录会被 IN 子查询自动过滤掉，导致条件失效；更隐蔽的是，如果子查询返回空集，整个 OR 表达式会退化为只依赖左边条件。
- 务必把
NULL处理显式写进条件：加AND user_id IS NOT NULL - 用
EXISTS替代IN更安全，尤其当子查询可能为空或含NULL时 - 多条件组合优先用括号明确优先级：
(status = 'pending') OR (user_id IS NOT NULL AND EXISTS (...))
UPDATE 设置状态位比 DELETE 更可控，但要注意索引失效风险
用 UPDATE orders SET deleted_at = NOW(), status = 'deleted' WHERE ... 是推荐做法，避免数据丢失、外键断裂和审计断链。但问题常出在后续查询没适配新状态位——比如原来查 WHERE status != 'deleted'，结果漏掉 NULL 值或历史脏数据。
- 所有读取逻辑必须同步改写，补上
deleted_at IS NULL或status NOT IN ('deleted', 'archived') - 给
deleted_at和status建联合索引，否则带WHERE deleted_at IS NULL AND status = 'active'的查询可能全表扫 - 别在
WHERE里对deleted_at做函数操作，比如DATE(deleted_at) = '2024-01-01'，会跳过索引
批量操作必须加 LIMIT + 分页循环，否则锁表时间不可控
直接 UPDATE orders SET status = 'deleted' WHERE created_at 可能锁住几百万行，阻塞线上写入。MySQL 默认事务下，这种语句会持有行锁直到事务结束；PostgreSQL 虽然 MVCC 更宽松，但大事务仍会拖慢 vacuum。
- 用
LIMIT 5000控制单次更新量，配合WHERE id > ?游标分页（不是OFFSET） - 每次执行后加
SLEEP(0.1)（MySQL）或pg_sleep(0.1)（PG），降低系统负载 - 确认数据库已开启
innodb_lock_wait_timeout（MySQL）或调整lock_timeout（PG），避免长等待卡死应用
软删除字段命名和默认值不统一，会导致 ORM 层行为错乱
Django 的 soft_delete、Laravel 的 softDeletes()、SQLAlchemy 的 query.filter(Model.deleted_at.is_(None)) 都依赖固定字段名和默认值。如果表里叫 is_deleted 且类型是 TINYINT(1)，ORM 很可能读不到预期逻辑。
- 统一用
deleted_at TIMESTAMP NULL DEFAULT NULL，而不是布尔型或字符串 - 建表时显式加约束：
CONSTRAINT chk_deleted_at CHECK (deleted_at IS NULL OR deleted_at - 如果已有字段命名混乱，别靠注释或文档“约定”，直接改列名并同步改所有 DAO 层代码
UPDATE，而是确保所有地方都意识到：它已经不是“删”，而是一次状态广播。 
