立即停手并停止所有写操作；补救依赖备份、从库同步或ROW格式binlog闪回；预防需启用sql_safe_updates=1、最小权限管控及避免LIMIT误用。
DELETE 语句没加 WHERE 就执行了怎么办
立刻停手，别再执行任何写操作。MySQL 默认不开启事务自动提交时，DELETE 一旦执行就无法回滚；哪怕开了 AUTOCOMMIT=1，也只会立刻落盘。生产库上没 WHERE 的 DELETE 基本等于删库边缘试探。
补救手段非常有限：依赖备份（全量 + binlog）、或从从库拉取数据、或用闪回工具（如 mysqlbinlog --flashback，但要求 binlog 格式为 ROW 且未过期）。这些都不是“防止”，而是“擦屁股”。
- 开发/测试环境务必设置
sql_safe_updates=1（MySQL），它会拒绝所有没WHERE或没用到索引字段的UPDATE/DELETE - 连接数据库前先执行
SET SQL_SAFE_UPDATES = 1，比改配置更灵活 - DBA 应禁止应用账号拥有
DROP和无条件DELETE权限，最小权限原则不是口号
为什么 LIMIT 不是 DELETE 的安全兜底
LIMIT 看似能控制删除行数，但它在 DELETE 中的行为和 SELECT 不同：它不保证顺序，也不保证可重复——同一语句多次执行可能删掉不同行，尤其表有并发写入时。
更关键的是，MySQL 5.6+ 虽支持 DELETE ... LIMIT N，但 PostgreSQL、SQL Server、SQLite 都不支持该语法；Oracle 根本没有 LIMIT，得用 ROWNUM 或 FETCH FIRST 替代，写法不通用。
- 不要把
LIMIT当成防误删开关，它解决不了逻辑错误（比如WHERE status = 'active'写成= 'inactive'） - 如果真要用，必须配合明确排序：
DELETE FROM orders WHERE created_at ，否则删哪 1000 行完全不可控 - 在分页清理旧数据场景下，优先用主键范围（
id ）替代 <code>LIMIT，更稳定、可预测、易重试
怎么让 WHERE 条件真正生效且不易写错
写 WHERE 不是加个等号就行。常见问题包括：字段类型隐式转换（比如字符串 ID 用数字比较）、NULL 判断写成 = NULL、大小写敏感导致匹配失败（尤其在 utf8mb4_0900_as_cs 排序规则下）。
最稳妥的方式是「先查后删」：把 DELETE 的 WHERE 拆出来，单独跑一遍 SELECT COUNT(*) 和 SELECT * LIMIT 5，确认结果集符合预期再删。
- 所有字符串值必须用单引号包裹：
WHERE name = 'admin'，而不是= admin（会被当列名） - 涉及时间字段，统一用
STR_TO_DATE()或标准格式'2024-01-01 00:00:00'，避免函数索引失效 - 用
EXPLAIN DELETE ...（MySQL 8.0.21+ 支持）看是否命中索引；没走索引的WHERE条件，删得慢还容易锁表
自动化防护：客户端与中间件层能做什么
靠人写对 WHERE 不现实，尤其 ORM 动态拼 SQL 时。真正有效的防护在链路更上游：驱动、ORM、代理层。
例如 Python 的 pymysql 可以封装一个 safe_delete() 函数，强制校验 kwargs 中是否存在非空 where 参数；MyBatis 的 <delete> 标签可配合自定义拦截器，扫描 SQL 是否含 WHERE 关键字并拦截无条件语句。
- ProxySQL 或 MaxScale 可配置 SQL 重写规则，自动给不带
WHERE的DELETE加上WHERE 1=0（只告警不执行） - 开发本地 MySQL 客户端（如 DBeaver）启用「执行前确认」+「高亮无 WHERE DELETE」插件，视觉提醒比文档有用十倍
- CI 流程中用
sqlfluff或正则扫描代码库里的DELETE FROM \w+后是否紧跟WHERE，卡住不合规提交
最深的坑不在语法，而在「以为加了 WHERE 就安全」——比如 WHERE user_id = ? 却传入了 None，最终变成 WHERE user_id = NULL，而它永远不成立，于是删了全表。这种空值穿透问题，光靠语法检查发现不了，得结合参数绑定日志和单元测试覆盖边界值。
