必须先用select验证where条件是否命中目标行，包括替换delete为select 、用count()预估行数、检查join逻辑、确认order by和limit、验证字段类型与索引，再执行带事务的delete并校验影响行数。
先用SELECT验证WHERE条件是否命中目标行
DELETE语句不带预览机制，WHERE写错就直接删，没机会反悔。所以执行前必须把DELETE替换成SELECT *，跑一遍完全相同的条件逻辑。
常见错误现象：用status = 0本意是删“禁用用户”，结果表里status字段是字符串类型，实际存的是'inactive'，SELECT一跑发现0行——立刻发现问题；若直接删，表面成功但实际没删任何数据，还可能掩盖业务逻辑缺陷。
- 务必带上
ORDER BY和LIMIT（如ORDER BY id DESC LIMIT 10），确认最新/最旧的几条是否真在目标范围内 - 涉及时间范围时，别裸写
'2025-01-01'，补全为'2025-01-01 00:00:00'或用STR_TO_DATE()，避免隐式转换导致索引失效、查不到数据 - 多表
JOIN删除前，SELECT也要用同样JOIN结构，否则关联逻辑对不上
用COUNT(*)预估影响行数，警惕“0行”或“超预期”
SELECT COUNT(*)比SELECT *更快，尤其对大表。它帮你快速判断数量级是否合理——比如删“30天前日志”，返回872行是正常，返回872000就得暂停，查是不是时间条件漏了索引或写反了比较符。
注意：MySQL里COUNT(*)在无WHERE时可能走元数据（极快），但加了条件后基本都走索引扫描或全表扫描，别把它当成毫秒级操作。
- 如果
COUNT(*)返回0，先检查字段名拼写、大小写、NULL值处理（比如status != 1不包含NULL） - 如果返回行数极大（如>10万），别直接删，考虑分批（
LIMIT 1000循环）或换用TRUNCATE（仅限整表清空） - PostgreSQL中
COUNT(*)在大表上可能较慢，可配合EXPLAIN看执行计划，确认是否走了索引
涉及多表JOIN时，必须验证关联逻辑和别名指向
MySQL的DELETE t FROM table1 t JOIN table2 s ON ...语法容易写错别名位置。删错表、删多表、删空表都源于SELECT验证阶段没还原相同结构。
典型翻车点：DELETE u FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'cancelled'，本意只删用户，但SELECT u.* FROM users u JOIN orders o ...一跑发现匹配了500个用户——其中有些用户有多个已取消订单，被重复计入，实际DELETE只会删一次（主键唯一），但数量预估偏差会误导你。
- 验证时
SELECT必须显式写出目标表别名（如u.*），不能只写* - 确认
JOIN字段（如orders.user_id）和WHERE字段（如orders.status）都有索引，否则SELECT COUNT(*)都会慢到超时 - PostgreSQL或SQL Server不支持MySQL式
DELETE ... JOIN，验证语句得改写成EXISTS或USING子句，语法差异必须同步覆盖
生产环境必须加事务并检查@@ROWCOUNT或RETURNING
即使SELECT验证过了，执行时也可能因并发修改、触发器拦截、外键约束失败等导致实际删除行数≠预估数。靠事务+影响行数校验是最后一道防线。
MySQL里删完立刻查SELECT ROW_COUNT()，值必须等于你之前COUNT(*)的结果；PostgreSQL必须用WITH deleted AS (DELETE ... RETURNING 1) SELECT COUNT(*) FROM deleted，不能依赖客户端输出的DELETE 42——脚本里不可靠。
- 别在
DELETE和ROW_COUNT()之间插任何其他语句，哪怕SELECT 1也会清空该值 - SQL Server用
@@ROWCOUNT，但它在IF或SET之后立即失效，必须紧跟DELETE后读取 - Python里用
cursor.rowcount，但psycopg2对不含RETURNING的DELETE可能返回-1，必须提前约定好SQL写法
真实场景里，最常被跳过的不是“加事务”，而是“验证ORDER BY结果”。比如删“最早创建的100条日志”，SELECT * FROM log ORDER BY created_at ASC LIMIT 100没加ORDER BY，结果删的是随机100行——因为没排序时数据库不保证顺序。
