必须开启SQL_SAFE_UPDATES、强制WHERE条件含索引列、每次操作前用SELECT验证结果集——三步缺一不可；它仅会话级生效，不防TRUNCATE/DROP，且WHERE须命中主键或唯一索引，否则报ERROR 1175。
必须开启 SQL_SAFE_UPDATES、强制带 WHERE（且字段有索引）、每次操作前先用 SELECT 验证结果集——这三步缺一不可，否则不是“可能误删”，而是“大概率已删”。
为什么 SQL_SAFE_UPDATES = 1 有时像没开一样
它只对当前会话生效，且只拦 UPDATE 和 DELETE，对 TRUNCATE、DROP、子查询形式的 WHERE 完全无效。常见失效场景包括：
- 你在 Navicat 里 SET 了，但应用代码用另一个连接直连 MySQL，该设置不继承
- 用的是
root或带SUPER权限的账号，MySQL 默认跳过安全限制 -
WHERE created_at > '2025-01-01'中created_at没索引，SQL_SAFE_UPDATES会直接报错ERROR 1175 (HY000)，这不是失效，是它真正在起作用 - 在 my.cnf 的
[mysqld]段加sql_safe_updates = 1是无效的——必须加在[mysql]客户端段，或用SET SESSION
怎么写 WHERE 才真正安全，不靠运气
写 WHERE 不是语法正确就行，关键是它在执行时是否命中预期行。最容易翻车的是隐式类型转换和 NULL 判断：
-
user_id = 'abc123'：如果user_id是BIGINT，MySQL 会把字符串转成数字，结果变成user_id = 0，可能删掉所有未初始化 ID 的记录 -
status = NULL永远不成立，必须写status IS NULL - 时间字段别裸写
'2025-01-01'，统一用'2025-01-01 00:00:00'或STR_TO_DATE('2025-01-01', '%Y-%m-%d')，避免函数导致索引失效 - 每次执行
DELETE前，必须先跑两遍SELECT：SELECT COUNT(*) FROM ... WHERE ...看数量，再SELECT * FROM ... WHERE ... LIMIT 5看具体数据是否符合业务语义
为什么不能依赖 LIMIT 当安全开关
LIMIT 在 DELETE 里不保证顺序，也不可重复。同一语句并发执行两次，很可能删掉不同行：
- 没
ORDER BY的DELETE ... LIMIT 1000，MySQL 按内部存储顺序删，无法预测删哪 1000 行 - 表有并发写入时，
LIMIT的“第 1000 行”每次都不一样，重试风险极高 - 跨数据库不通用：PostgreSQL、SQL Server 不支持
DELETE ... LIMIT，Oracle 要用ROWNUM，硬写会锁死迁移路径 - 真要分批删旧数据，优先用主键范围：
DELETE FROM logs WHERE id < 1000000 AND created_at < '2022-01-01'，稳定、可重试、易监控
权限和账号配置才是最后一道物理防线
再小心的操作也会出错，所以生产环境里，绝大多数账号根本不该有 DELETE 权限：
- BI 报表、运维排查、前端查询服务，只给
SELECT权限，用GRANT SELECT ON mydb.orders TO 'reporter'@'%'，别用GRANT ALL - 禁用
DROP、TRUNCATE、ALTER权限，这些操作无法被SQL_SAFE_UPDATES拦截 - 删除类任务用专用账号，比如
deleter_prod，只授DELETE权限，且仅限指定表，不开放information_schema查询 - Navicat 连生产库后第一件事不是写 SQL，而是执行：
SET AUTOCOMMIT = 0;+SET SQL_SAFE_UPDATES = 1;——关自动提交才能回滚，开安全模式才能拦截危险条件
最常被忽略的一点：所有防护都基于“人会按流程操作”。但真实场景里，有人会复制粘贴错误的 WHERE，有人会忘记改测试库连接，有人会在凌晨三点凭记忆敲 SQL。所以 SQL_SAFE_UPDATES 和最小权限不是备选方案，是默认开关；而 SELECT 验证不是可选步骤，是 DELETE 命令的前置必要条件。
