生产环境禁用裸DELETE，因其不可逆、易引发锁等待与主从延迟，且恢复依赖binlog回滚或延时从库，误操作将导致数小时故障；软删除需通过deleted_at字段、统一视图、联合索引及多层管控保障一致性。
生产环境禁用裸 DELETE，不是因为语法难，而是它一旦执行就不可逆——没有“回收站”，没有后悔键，连 ROLLBACK 都救不回来。
物理 DELETE 为什么在生产里等于“埋雷”
MySQL 的 DELETE FROM table WHERE ... 看似可控，但实际运行时会逐行加锁、写 undo 日志、刷 binlog，这些动作在大表或高并发下极易引发锁等待、主从延迟甚至主库夯死。更关键的是：它删掉的数据，恢复成本极高——要么靠 binlog 回滚（需人工筛选、停服、重放，误差一步全崩），要么靠延时从库（依赖配置且窗口有限）。一次误操作，可能就是数小时故障+客户投诉。
-
DELETE是 DML，能进事务，但仅限“未提交前”；一旦 COMMIT，undo 日志很快被覆盖，无法回溯 - 没加
WHERE条件的DELETE在生产库属于高危操作，多数 DBA 会直接禁用该账号的DELETE权限 - 外键级联删除可能触发意料之外的关联数据清除，排查困难
软删除不是“多加个字段”那么简单
真正落地软删除，核心是把“标记”和“过滤”解耦：标记靠 UPDATE，过滤靠统一入口。比如用 deleted_at 字段（而非 is_deleted）：
-
deleted_at为NULL表示未删，非空表示已删且记录时间，比布尔值多一层审计能力 - 所有业务查询必须走视图或 ORM 作用域，例如创建视图
CREATE VIEW user_active AS SELECT * FROM user WHERE deleted_at IS NULL - 索引要覆盖
deleted_at字段，否则WHERE deleted_at IS NULL可能触发全表扫描
DELETE 和软删除的性能差异在哪
很多人以为软删除慢，其实是用法问题。DELETE 的慢来自行锁、日志写入和事务开销；而软删除的慢往往源于漏加索引或查询未走视图。真实瓶颈点不同：
- 高频更新
deleted_at字段本身开销极小，InnoDB 对单字段 UPDATE 优化得很好 - 如果查询写成
SELECT * FROM user WHERE status = 1 AND deleted_at IS NULL却没给(status, deleted_at)建联合索引，性能反而比物理删除后查原表还差 - TRUNCATE 或 DROP 虽快，但它们清空整表，和“删某几条”的业务语义根本不匹配，不能混用
软删除真正的复杂点不在实现，而在一致性——所有新写的 SQL、所有老的存储过程、所有第三方报表工具，都得默认忽略已删数据。漏一处，就等于数据泄露。这没法靠一个字段解决，得靠规范、视图、权限、CI 检查四层卡口。
