sql_safe_updates=1能实时拦截无索引where或无where的update，原理是执行前校验执行计划是否走索引（key非空、type为const/eq_ref/range），而非语法检查；需会话级set并select@@sql_safe_updates验证为1，且注意super权限账号和客户端兼容性。
开就拦，不开不拦——sql_safe_updates=1 是唯一能实时阻止无条件 UPDATE 的机制，但它只在语句执行前校验 WHERE 是否“可索引”，不是语法检查。
为什么 SET sql_safe_updates = 1 后还报 ERROR 1175
这不是配置失败，而是 MySQL 判定你的 WHERE 条件无法高效定位数据。它不看“有没有写 WHERE”，只看执行计划里 key 是否非空、type 是否为 const/eq_ref/range（且字段是主键、唯一索引或已建普通索引）。
-
UPDATE users SET name = 'a' WHERE id = 123→ 放行（id是主键） -
UPDATE logs SET level = 'WARN' WHERE msg LIKE '%error%'→ 报错（msg无索引，EXPLAIN SELECT * FROM logs WHERE msg LIKE '%error%'显示type: ALL） -
UPDATE orders SET status = 'done' WHERE order_no = 'OD2026' LIMIT 100→ 放行（order_no有唯一索引，且带LIMIT） -
UPDATE t SET x = 1 WHERE created_at > '2025-01-01'→ 即使created_at是主键，也大概率报错（范围条件在某些版本中不被安全模式认可）
怎么让设置真正生效，而不是“看起来开了”
它默认是会话级的，新连接不继承。别只在当前终端 SET sql_safe_updates = 1 就以为万事大吉。
- 开发环境：在
my.cnf的[mysql]段加safe-updates（仅对原生命令行客户端生效） - 生产环境：在
my.cnf的[mysqld]段加init_connect='SET sql_safe_updates=1;'，再执行SET GLOBAL sql_safe_updates = 1（需 SUPER 权限） - 验证是否真生效：
SELECT @@sql_safe_updates;返回1；断开重连后再查一次，确认没回退 - Navicat / DBeaver / JDBC 连接默认不读
my.cnf的[mysql]段，必须在连接字符串里显式加参数，或在会话开头手动SET
误更新已经发生？LIMIT 不是保险丝
LIMIT 在单表 UPDATE 中合法，但它只控制“最多改多少行”，不保证“改哪几行”。MySQL 5.7+ 不保证顺序，除非你用子查询 + ROW_NUMBER() 预筛 ID。
-
UPDATE t SET x = 1 WHERE y = 2 LIMIT 10→ 若y = 2匹配 100 行，MySQL 随机选 10 行改 - 真正可控的做法：
SELECT id FROM t WHERE y = 2 ORDER BY id LIMIT 10拿出 ID 列表，再UPDATE t SET x = 1 WHERE id IN (1,2,...) - 上线前必做：
START TRANSACTION包裹操作，执行后立刻SELECT ROW_COUNT();核对影响行数，不符则ROLLBACK
最容易被忽略的是：开发机配了 safe-updates，但生产应用直连 MySQL 时用的是 JDBC，默认不触发该设置；还有就是 root 或拥有 SUPER 权限的账号，MySQL 默认跳过 init_connect 和 sql_safe_updates 检查——这类账号不该直接用于日常运维。
