必须加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 也不会保留被删记录的镜像。所有安全措施，本质都是在给“按下回车”这个动作加延迟、加验证、加退路。