mysql不加where会静默全表更新，仅当启用sql_safe_updates=1时才拦截；该配置要求where必须含主键、唯一索引或普通索引列，否则报error 1175。
MySQL 执行 UPDATE 时不加 WHERE 条件，**本身不会报错**——它会静默地、立即更新整张表所有行。你看到的报错，是人为开启了安全防护机制后的拦截结果，不是 MySQL 默认行为。
sql_safe_updates=1 是唯一能拦住无 WHERE 的 UPDATE 的配置
MySQL 默认允许 UPDATE table SET col=1; 这种语句执行。只有当你显式启用 sql_safe_updates（值为 1）后，它才会拒绝两类操作：
- 没写
WHERE子句的UPDATE或DELETE -
WHERE写了，但条件字段**没索引**（比如WHERE msg LIKE '%error%'，而msg列没建索引）
这个参数必须在连接建立前生效。常见误操作：
- 在 MySQL Workbench 的「Preferences → SQL Editor」里勾选了 Safe Updates，但没重新连接——旧连接不生效
- 用命令行登录时没带
--safe-updates参数，或没在my.cnf里全局配sql_safe_updates=1 - 开发账号没
SUPER权限，无法在会话中执行SET sql_safe_updates=1
报错信息里 “uses a key column” 到底指什么
错误提示中的 “key column” 不是指主键（PRIMARY KEY），而是泛指**任何有索引的列**，包括：
- 主键（
id） - 唯一索引（
UNIQUE KEY order_no） - 普通索引（
INDEX status） - 联合索引的最左前缀列（
INDEX (a,b,c)中的a或a,b）
反例：即使写了 WHERE created_at > '2025-01-01'，只要 created_at 没建索引，仍报 ERROR 1175。别只看语法有没有 WHERE，得看执行计划能不能走索引。
为什么开了 safe mode 还可能漏防
安全模式只拦住「当前连接」里的语句，但它不解决以下真实风险：
- 开发人员绕过 GUI 工具，直接用
mysql -e "UPDATE ..."命令执行（未启用 safe mode） - 应用代码拼 SQL 时变量为空，导致
WHERE user_id = ?变成WHERE user_id = ''，实际等效于无条件更新 - 索引失效：字段有索引，但用了函数或类型隐式转换，如
WHERE DATE(create_time) = '2026-06-01'，索引无法命中
真正兜底的不是参数开关，而是流程：上线前用 EXPLAIN 看执行计划、影响行数预估、事务包裹 + SELECT ROW_COUNT() 核对、生产库禁止开发直连高权限账号。
最容易被忽略的一点：安全模式只校验语法和索引，不校验业务逻辑是否合理。哪怕 WHERE id IN (1,2,3) 走了主键索引，如果这三条 ID 是线上核心用户，误更新照样灾难——防护机制再严，也防不住写错的 WHERE 条件本身。
