删除数据前必须严格验证where条件，执行select复核；禁止无where删除；务必加limit分批操作；检查外键级联影响；操作前后需备份待删数据。
必须先确认 WHERE 条件是否精确匹配目标行，否则极大概率误删整表或大量无关数据。
WHERE 条件没加或写错导致全表删除
MySQL 默认不开启安全模式（SQL_SAFE_UPDATES=0），DELETE FROM users; 这种语句会直接清空全表，且无法回滚（DDL 类操作虽不属 DDL，但 InnoDB 的 DELETE 无事务外保障，一旦提交即生效）。
- 执行前务必用
SELECT COUNT(*)或SELECT id, ...复现相同WHERE条件，验证返回行数和样本内容 - 禁止在生产环境使用无
WHERE的DELETE；即使加了WHERE，也要检查字段名拼写、表别名作用域、NULL 判断逻辑（如status = NULL应为status IS NULL） - 避免隐式类型转换：比如
user_id = '123abc'可能被 MySQL 转成user_id = 123，批量误删
没加 LIMIT 的单表 DELETE 风险极高
即便 WHERE 正确，未限制数量的 DELETE 在大表上可能锁表过久、触发主从延迟、甚至 OOM。阿里巴巴开发规范明确要求：DELETE 和 UPDATE 必须带 LIMIT。
- 先试删 1 行：
DELETE FROM orders WHERE status = 'timeout' LIMIT 1;，观察日志、监控、主从同步状态 - 若需删多行，分批执行，例如每次
LIMIT 1000，间隔几秒再下一批 - 注意：
LIMIT在 MySQL 中不支持子查询，也不能用于多表DELETE的非主表部分
外键约束与级联删除可能引发连锁反应
如果目标表被其他表通过 FOREIGN KEY ... ON DELETE CASCADE 引用，一条 DELETE 可能自动连删下游几十张表的数据，而你完全没意识到。
- 查依赖：
SELECT CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME, REFERENCED_TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_SCHEMA = 'your_db' AND REFERENCED_TABLE_NAME = 'target_table'; - 临时禁用外键检查（仅限紧急修复，且必须配
SET FOREIGN_KEY_CHECKS = 0;+COMMIT+SET FOREIGN_KEY_CHECKS = 1;）风险极大，不推荐 - 更稳妥的做法是显式查出待删主键，再逐个检查各关联表中是否存在对应记录
真正危险的不是“会不会删”，而是“删完才发现删错了”。所有检查都应在同一事务快照下完成，且操作前后必须有备份——不是靠 mysqldump 全库，而是针对该表做 mysqldump --where="..." 或 SELECT INTO OUTFILE 导出待删数据副本。这一步被跳过，90% 的恢复请求都只能靠 binlog 解析硬扛。
