结论：不加 WHERE 的 DELETE 是生产环境最高危操作之一，90%以上误删事故源于此；安全删除须先用 SELECT 验证范围，确认类型、数量、主键及关联数据后再执行。
直接说结论：不加 WHERE 的 DELETE 是生产环境最高危操作之一，90%以上的误删事故都源于此。安全删除不是靠“小心”，而是靠固定动作和验证闭环。
执行前必须先用 SELECT 验证删除范围
这是最不可跳过的一步。哪怕条件看起来很明确，也要先查出实际要删的行——类型、数量、主键值、关联数据都要眼见为实。
- 错误做法：
DELETE FROM orders WHERE status = 'cancelled' AND created_at 直接执行 - 正确做法：先运行
SELECT COUNT(*), MIN(id), MAX(id) FROM orders WHERE status = 'cancelled' AND created_at - 再抽样看几条：
SELECT * FROM orders WHERE status = 'cancelled' AND created_at - 特别注意：如果条件涉及函数（如
DATE(created_at)）或隐式转换（如字符串 vs 数字），SELECT结果可能和DELETE实际影响行数不一致
强制使用事务包裹 DELETE 操作
哪怕数据库默认自动提交，也得显式开事务——这不是为了“万一出错能回滚”，而是为了让你有意识地确认影响行数后再决定是否提交。
- MySQL / PostgreSQL 示例：
BEGIN; DELETE FROM logs WHERE ts - SQL Server 示例：
BEGIN TRAN; DELETE FROM audit_log WHERE event_time - 关键点：
SELECT ROW_COUNT()或@@ROWCOUNT必须紧跟DELETE后执行，不能隔语句 - 如果影响行数远超预期（比如预估删100行，实际返回10万），立刻
ROLLBACK，别犹豫
大表删除必须分批 + LIMIT（MySQL）或 TOP N（SQL Server）
单次删几万行以上，会锁表、打爆事务日志、拖慢整个实例。分批不是“更稳”，是唯一可行方案。
- MySQL：
DELETE FROM huge_table WHERE processed = 0 LIMIT 1000，循环执行直到ROW_COUNT() = 0 - SQL Server：
DELETE TOP (1000) FROM huge_table WHERE processed = 0 - 每批之间加
SLEEP(0.1)（MySQL）或WAITFOR DELAY '00:00:00.1'（SQL Server），缓解压力 - 避免在高并发写入时段执行；优先选凌晨或业务低峰
- 注意：PostgreSQL 不支持
LIMIT在DELETE中，得用ctid或子查询分页模拟
关联删除慎用子查询，优先考虑 JOIN 语法（MySQL）或 CTE（PostgreSQL/SQL Server）
子查询删除容易因性能差导致超时，且难以预估影响行数；JOIN 或 CTE 能让执行计划更可控，也方便提前 SELECT 验证。
- MySQL 推荐写法：
DELETE o FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'archived' - PostgreSQL 推荐写法：
WITH to_delete AS (SELECT o.id FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'archived') DELETE FROM orders WHERE id IN (SELECT id FROM to_delete) - 永远不要写
DELETE FROM t1 WHERE id IN (SELECT id FROM t2 WHERE ...)这类嵌套子查询，尤其当t2数据量大时，可能全表扫描 - 如果关联表无索引（比如
customers.status未建索引），先加索引再删，否则删一天也删不完
真正容易被忽略的，不是语法对不对，而是“删完之后没人检查”。删完必须查 SELECT COUNT(*) 对比，再抽样查残留数据——很多“删干净了”的假象，其实是因为条件漏写了 AND 或括号错位。
