sql_safe_updates=1是唯一靠谱兜底机制，因mysql不检查语法where而只验执行计划是否走主键或唯一索引；开启后无where、无索引where或非唯一索引where均报error 1175，仅含主键/唯一索引where或带limit才放行。
必须开启 sql_safe_updates=1，否则漏写 WHERE 就是静默炸库，没有警告、不回滚、不可逆。
为什么 sql_safe_updates=1 是唯一靠谱的兜底机制
MySQL 不检查语法里有没有 WHERE 字样，只看执行计划能不能走主键或唯一索引。开了这个参数后，以下语句会被直接拒绝（报 ERROR 1175）：
-
UPDATE users SET status = 'inactive';（无WHERE） -
UPDATE logs SET level = 'WARN' WHERE msg LIKE '%error%';（msg没索引，执行计划是type: ALL） -
UPDATE orders SET paid = 1 WHERE customer_name = 'Alice';（customer_name只有普通索引，非唯一）
但这些会放行：
-
UPDATE users SET name = 'a' WHERE id = 123;（id是主键） -
UPDATE orders SET status = 'done' WHERE order_no = 'OD2026' LIMIT 100;（order_no有唯一索引 +LIMIT）
怎么确认它真生效了，而不是白设
别改全局配置，也别信 Navicat 或 DBeaver 的“安全模式”开关——它们不读 sql_safe_updates。只做两件事：
- 当前连接里执行：
SET SESSION sql_safe_updates = 1; - 立刻验证：
SELECT @@sql_safe_updates;，返回1才算成功
退出连接就失效，不影响别人，也不用重启 MySQL。开发环境每天连上第一件事就是这行命令。
开了还报 ERROR 1175？先查执行计划，别急着关开关
报错 ≠ 你写错了 WHERE，只是 MySQL 判定它没法高效执行。优先让语句合规：
- 用
EXPLAIN SELECT * FROM t WHERE ...看key列是否非空、type是否为const/eq_ref/range - 高频模糊字段补前缀索引：
ALTER TABLE logs ADD INDEX idx_msg (msg(100)); - 用主键范围替代模糊条件：
UPDATE big_table SET processed = 1 WHERE id BETWEEN 1000 AND 2000; - 真要模糊更新又没索引？先
SELECT id FROM t WHERE ...拿出 ID 列表，再用IN更新
LIMIT 不是保险丝，别把它当 WHERE 的替身
UPDATE t SET x = 1 WHERE y = 2 LIMIT 10 只控制最多改 10 行，但 MySQL 仍会扫描并加锁所有 y = 2 的行——顺序不可控，除非你加 ORDER BY（原生 UPDATE 不支持）。真正防误操作靠三件套：
-
sql_safe_updates=1拦住无条件或低效条件 -
EXPLAIN验证 WHERE 是否真走索引 - 事务包裹 +
ROW_COUNT()核对影响行数
最常被忽略的是：sql_safe_updates 对多表 UPDATE 同样生效，但要求每张表的 WHERE 条件里至少有一个主键或唯一索引字段——比如 UPDATE a JOIN b ON a.id = b.a_id SET a.x = 1 WHERE a.id = 123 AND b.status = 'done'，这里 a.id 合规，但 b.status 必须也是唯一索引列，否则照样报错。
