必须开启 sql_safe_updates=1，这是唯一能实时拦截无条件 update 的原生机制；它强制要求 where 条件含主键或唯一索引字段，防止全表误更新，需会话级启用并配合影响行数校验。
必须开启 sql_safe_updates=1，这是唯一能实时拦截无条件 UPDATE 的原生机制。
为什么只靠“习惯”和“复查”拦不住误操作
人在疲劳、赶工、复用旧 SQL 时，漏写 WHERE 是高频低级错误。它不报错、不警告，执行完就全表覆盖——等发现时 binlog 可能已轮转，备份可能过期。你无法依赖“下次注意”，只能靠数据库强制卡住。
常见错误现象：UPDATE users SET status = 'active'; 直接生效百万行；UPDATE orders SET paid_at = NOW(); 把未付款订单也标为已付。
- MySQL 默认
sql_safe_updates是0，完全不设防 - 工具如 DBeaver、Navicat 不自动启用该模式，需手动设置
- 即使写了
WHERE，若字段没主键或唯一索引，仍会被拦截（这是故意设计，不是 bug）
如何正确启用并验证 sql_safe_updates
别改全局配置，会波及运维脚本或监控任务。只在当前会话启用最安全：
执行：SET SESSION sql_safe_updates = 1;
立刻验证：SELECT @@sql_safe_updates; —— 返回 1 才算成功。
注意：SET GLOBAL sql_safe_updates = 1 对已有连接无效，且重启后失效；生产环境 DBA 通常禁用 GLOBAL 设置权限。
- 开发/测试环境：每次连上先跑一遍
SET SESSION，加到客户端启动脚本里 - CI/CD 脚本中执行 DML 前，显式加上该语句，避免依赖环境默认值
- Java 应用通过 JDBC 连接时，在 URL 后加
?sessionVariables=sql_safe_updates=1
被 ERROR 1175 拦住时，别急着关开关
报错 ERROR 1175 (HY000): You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column，说明 MySQL 认为你这条语句有风险，但不等于你写错了——它只是要求你“证明自己可控”。
- 先用
EXPLAIN SELECT * FROM t WHERE ...看key列是否非空、type是否为const或eq_ref - 确认 WHERE 字段是主键、或带
UNIQUE约束——普通INDEX不行 - 真要模糊更新（如
WHERE content LIKE '%error%'），先SELECT id FROM t WHERE ...拿 ID 列表，再UPDATE ... WHERE id IN (...) - 批量更新允许带
LIMIT，但注意：MySQL 不保证顺序，必须加ORDER BY（需用子查询或临时表绕过语法限制）
sql_safe_updates 不是银弹，必须配合其他动作
它只管“能不能执行”，不管“该不该执行”。哪怕语句合规，仍可能逻辑错误——比如 WHERE order_no = 'OD2026' 匹配了 10 行，你本意只改其中 1 行。
- 所有重要 UPDATE 前，先跑等效
SELECT COUNT(*)确认影响行数是否符合预期 - 事务内执行后，立刻检查
ROW_COUNT()返回值，== 0就该中断流程，而不是继续发消息或调下游 - MyBatis/JPA 等框架中，
@Update或save()隐式生成的 SQL 也要受控——它们同样触发sql_safe_updates检查 - 真正容易被忽略的是：MySQL 和 PostgreSQL 对
ROW_COUNT()为 0 的处理是静默的，框架日志里常显示“执行成功”，实际什么都没改
