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