MySQL中不建议对业务核心表使用DELETE物理删除，根本原因是不可逆、难追溯、易引发连锁问题；应采用逻辑删除（如is_deleted字段）并配合索引优化、定期归档与复合唯一约束等治理措施。
MySQL 中不建议对业务核心表使用 DELETE 物理删除，根本原因不是“不能删”，而是删完后不可逆、难追溯、易引发连锁问题——逻辑删除（如加 is_deleted 字段）才是生产环境的默认安全策略。
误删数据无法快速恢复
执行 DELETE FROM users WHERE id = 123 后，InnoDB 并不会立刻擦除磁盘数据，而是标记为“可复用”，后续由 purge 线程异步清理。一旦被覆盖或未开启 binlog，数据实质丢失。而逻辑删除只是 UPDATE users SET is_deleted = 1, deleted_at = NOW() WHERE id = 123，恢复只需一行 UPDATE，5 秒内完成，不影响服务。
- 物理删除后恢复依赖备份+binlog+人工介入，平均耗时 30 分钟以上
- 逻辑删除天然支持“软回滚”，连事务都不用开
- 审计要求（如等保、GDPR）明确要求保留删除操作元信息，
deleted_by和deleted_at必须可查
查询性能不会因删除变差，但会因“不清理”变差
很多人以为逻辑删除必然拖慢查询，其实错在混淆了“是否加索引”和“是否删数据”。只要在 is_deleted 上建联合索引（如 (is_deleted, created_at)），带 WHERE is_deleted = 0 的查询性能几乎无损。真正导致慢的是：长期只标不归档，让主表膨胀到千万级仍不处理。
- 错误做法：
ALTER TABLE orders ADD COLUMN is_deleted TINYINT DEFAULT 0，然后从不归档 - 正确做法：配合生命周期策略，定期将
is_deleted = 1 AND deleted_at < DATE_SUB(NOW(), INTERVAL 6 MONTH)的数据迁出主表 - 索引设计必须包含
is_deleted，否则WHERE is_deleted = 0会全表扫描
唯一索引冲突问题比想象中更常见
用 TINYINT is_deleted DEFAULT 0 最容易踩坑：当业务要求“用户名唯一”，但允许用户注销后重注册，物理删除后新用户可复用同名；而逻辑删除若只设 0/1，UNIQUE(username) 会把已删和未删的同名用户一起拦住。
- 推荐方案：用
BIGINT delete_flag DEFAULT 0，删除时设为雪花 ID 或UNIX_TIMESTAMP()，既保留时间精度，又绕过唯一约束 - 或者改用复合唯一索引：
UNIQUE KEY uk_username_deleted (username, is_deleted)，让“已删的张三”和“未删的张三”视为不同记录 - 千万别在已有唯一索引的字段上直接加
is_deleted还不调索引——这是线上慢查高频诱因
逻辑删除不是加个字段就完事，它是一套需要索引配合、归档兜底、权限收敛的数据治理动作。最容易被忽略的点是：没人负责定期清理已删数据，结果一年后主表体积翻三倍，查询计划突然走错索引——这时候再优化，已经晚了。
