必须加WHERE条件，否则会清空整张表；MySQL默认自动提交，单条DELETE立即生效；执行前先用SELECT验证条件；优先用LIMIT限制删除行数。

执行 DELETE 前必须加 WHERE 条件

不带 WHERE 的 DELETE FROM table_name 会清空整张表，且无法通过事务回滚（除非在事务中且未提交），这是生产环境最常见、最致命的误操作。

• MySQL 默认开启自动提交（autocommit=1），单条 DELETE 语句执行即生效
• 即使你写了 BEGIN / START TRANSACTION，也必须显式 COMMIT 或 ROLLBACK，不能依赖“没提交就没事”
• 建议在执行前先用 SELECT COUNT(*) 和 SELECT * LIMIT 10 验证 WHERE 条件是否命中预期数据

优先用 LIMIT 限制删除行数

尤其在清理历史数据或调试阶段，LIMIT 是防止误删扩散的关键防线。MySQL 支持在 DELETE 中使用 LIMIT，但要注意语法位置和兼容性。

• DELETE FROM logs WHERE created_at 是合法且推荐的写法
• LIMIT 必须放在语句末尾，不能出现在 WHERE 之后、ORDER BY 之前（MySQL 8.0+ 支持 ORDER BY ... LIMIT，但低版本不支持）
• 如果要按顺序删（如保留最新 N 条），需配合 ORDER BY：例如 DELETE FROM events ORDER BY id DESC LIMIT 10000
• 注意：带 ORDER BY 的 DELETE ... LIMIT 在高并发下可能因索引竞争导致非预期行为，慎用于核心业务表

避免直接在主库执行大范围 DELETE

删除大量行（如百万级以上）会引发锁表、binlog 膨胀、从库延迟甚至 OOM。这不是语法问题，而是工程实践红线。

• 单次删除超过 1 万行，建议拆成小批次（如每次 1000 行），用循环 + SLEEP(0.1) 控制节奏
• 不要用 DELETE ... IN (SELECT ...) 删除大集合——子查询可能生成临时表，且 MySQL 5.7 及以前版本会锁全表；改用 JOIN 形式：

  DELETE t1 FROM orders t1 JOIN tmp_delete_ids t2 ON t1.id = t2.id;

• 考虑用归档表 + RENAME TABLE 替代大批量删除：先 INSERT INTO archive_table SELECT ...，再 DELETE 小批量，最后 DROP 归档表
• 确认 binlog 格式为 ROW（而非 STATEMENT），否则大删可能在从库重放失败

启用 SQL 审计与操作留痕

靠人肉检查无法杜绝风险，必须靠机制兜底。MySQL 本身不提供细粒度 DML 审计，需组合配置。

• 开启通用查询日志（general_log=ON）代价太高，仅限临时排障；生产应启用 audit_log 插件（MySQL Enterprise）或 Percona Server 的 audit_log 模块
• 对敏感库/表，可在应用层统一拦截：比如所有 DELETE 请求必须携带 /* audit: reason=xxx; by=user@host */ 注释，并由中间件校验
• DBA 应定期检查 information_schema.PROCESSLIST 或 Performance Schema 中的长事务、未提交事务，及时发现卡住的 DELETE
• 备份策略必须包含 mysqldump --single-transaction 或物理备份（如 xtrabackup），确保删错后能快速恢复到秒级精度

真正危险的不是不会写 DELETE，而是忘了它没有“回收站”——一旦提交，undo log 在事务结束时就失效，InnoDB 也不会保留被删记录的镜像。所有安全措施，本质都是在给“按下回车”这个动作加延迟、加验证、加退路。