sql_safe_updates=1可拦截无WHERE的UPDATE/DELETE，但仅限会话级生效，需确认WHERE含主键或唯一索引、或带LIMIT，否则报ERROR 1175。
不带 WHERE 子句的 UPDATE 语句会修改表中**每一行**，不是“可能出错”，而是“必然全改”——没有回旋余地，除非你有可用的备份或 binlog。
为什么 UPDATE 不写 WHERE 就会全表更新？
SQL 标准里，UPDATE 语句的语法允许省略 WHERE。MySQL、PostgreSQL 等主流数据库默认都执行它，不会主动拦截或警告。它不关心你是不是手滑、是不是忘了加条件，只按规则执行：匹配所有行，全部更新。
常见触发场景包括：
- 在 MySQL Workbench 或 DBeaver 中写完
UPDATE users SET status = 'active';，光标还在末尾，顺手按了 Ctrl+Enter - 复制上一条语句改字段，但漏删了原来的
WHERE id = 123 - 脚本中拼 SQL 字符串，
WHERE条件变量为空时没做校验，最终生成了无条件语句
sql_safe_updates 是什么，它怎么拦住危险语句？
sql_safe_updates 是 MySQL 唯一原生、轻量、生效快的安全机制。设为 1 后，它强制要求 UPDATE 必须满足以下**至少一项**才能执行：
-
WHERE子句中包含主键列（如WHERE id = 100） -
WHERE子句中包含唯一索引列（如WHERE order_no = 'OD2026'，且order_no有UNIQUE约束） - 带
LIMIT（如UPDATE logs SET level='WARN' WHERE msg LIKE '%timeout%' LIMIT 100）
注意：仅带普通索引字段（比如 WHERE name = 'Alice'，name 有 INDEX 但非 UNIQUE）仍会报 ERROR 1175 ——MySQL 要求的是“key column”，即主键或唯一索引列，不是任意索引。
如何开启并确保它真正起作用？
临时启用（推荐开发/日常使用）：
SET SESSION sql_safe_updates = 1;
确认是否生效：
SELECT @@sql_safe_updates;
若返回 1，说明已激活。退出当前连接后自动失效，不影响其他会话。
永久生效（需 DBA 权限）：
- 修改 MySQL 配置文件
my.cnf，在[mysqld]下添加：sql_safe_updates = ON - 或通过
init-file自动执行：[mysqld]<br>init-file = /opt/init.sql
，并在/opt/init.sql中写入SET GLOBAL sql_safe_updates = 1;
⚠️ 注意：SET GLOBAL 对已存在的连接无效，只影响新连接；且重启后若未写入配置，会恢复默认值 0。
安全模式下仍报 ERROR 1175？检查这三点
开启 sql_safe_updates 后还被拒绝，别急着关掉它，先查：
-
EXPLAIN你的WHERE条件是否真能走索引？用SHOW CREATE TABLE xxx;确认字段是否有主键或UNIQUE约束，而非普通INDEX - 是否用了函数或表达式导致索引失效？例如
WHERE DATE(created_at) = '2026-05-19'→ 改成WHERE created_at >= '2026-05-19' AND created_at - 是否误用了
LIMIT却没配WHERE？MySQL 要求UPDATE ... LIMIT必须同时带有效WHERE才放行（DELETE 则不同，可单靠LIMIT）
真正麻烦的不是“怎么开开关”，而是当业务逻辑天然依赖非索引字段做批量更新时——这时得补索引、拆分条件、或用主键范围代替模糊匹配，而不是关安全模式。
