删除前必须确认备份可用且经验证可还原，执行时用SELECT模拟、加主键范围限制、事务包裹并设超时，删后立即验证行数与执行计划并记录日志。
删除前必须确认表备份是否可用
生产环境删数据不是“执行完就完事”，而是“删之前得知道删错了怎么救”。很多团队用 mysqldump 或 pg_dump 备份，但没验证过备份文件能否还原——结果真出问题时发现压缩包损坏、权限不足或缺少 --single-transaction 导致备份不一致。
- 执行备份后立刻用
head -n 20 backup.sql看开头是否有正确表结构和注释 - MySQL 下检查是否含
SET FOREIGN_KEY_CHECKS=0;和CREATE TABLE，否则还原可能失败 - PostgreSQL 要确认是否用了
-Fc（自定义格式），否则pg_restore无法增量还原单表 - 别只备份结构，用
--no-create-info（MySQL）或--data-only（PG）单独导出当前数据快照，比全量备份更快回滚
用 SELECT 模拟 DELETE 的 WHERE 条件
直接写 DELETE FROM users WHERE status = 'inactive' 很危险——你根本不知道这个条件到底会命中多少行，也不知道 status 字段有没有索引，更不知道会不会误连到其他库。
- 先把
DELETE换成SELECT COUNT(*)，再换成SELECT id, status, updated_at LIMIT 10，人工核对数据是否符合预期 - 在 WHERE 中显式加上主键范围限制，比如
AND id BETWEEN 1000 AND 2000，避免全表扫描+锁表 - 如果用 ORM（如 Django ORM），别依赖
.filter(...).delete()，先.filter(...).values_list('id', flat=True)抽出 ID 列表，再分批操作 - 注意 MySQL 的
sql_mode是否含STRICT_TRANS_TABLES，否则某些隐式类型转换会让 WHERE 匹配出意外结果
用事务包裹 DELETE 并设置超时
哪怕只是删几千行，也可能因锁等待、主从延迟或长事务阻塞线上查询。不加控制的 DELETE 在高并发下等于埋雷。
- MySQL 必须用
BEGIN; DELETE ...; COMMIT;，不能靠自动提交——否则中断后无法回滚 - 在事务里加
SELECT SLEEP(0.1)（MySQL）或pg_sleep(0.1)（PG）人为降速，减少锁持有时间 - 应用层设置语句级 timeout：MySQL 客户端用
--connect-timeout=5 --execution-timeout=30，Python 的pymysql设read_timeout和write_timeout - 别在事务里混用 DDL（如
ALTER TABLE），MySQL 8.0+ 会自动提交事务，导致前面的 DELETE 无法回滚
删完立刻验证并记录影响范围
执行完 DELETE 不代表任务结束，而是刚进入风险观察期。没人看日志、没人查监控、没人比对前后行数，就等于没做完。
- 立刻执行
SELECT ROW_COUNT()（MySQL）或GET DIAGNOSTICS（PG）拿到真实影响行数，和预估数量对比 - 检查慢查询日志里是否出现该 DELETE 的执行计划，重点看
type是否为ALL（全表扫描）、key是否用了预期索引 - 用
SHOW ENGINE INNODB STATUS\G查看是否有长等待事务，特别是lock_wait相关字段 - 把操作命令、影响行数、执行时间、备份文件名写进运维日志，别只存在自己终端历史里
真正麻烦的从来不是“怎么删”，而是“删完谁来盯”——锁没释放、主从延迟突增、下游服务缓存没清，这些都不会报错，但会在凌晨三点让你手机震个不停。
