MySQL · 错误码速查
MySQL 错误 1175：安全更新模式拦下了没走索引的 UPDATE / DELETE，先改 WHERE，别急着关开关
1175 不是数据或权限出错，而是当前会话开着 sql_safe_updates=1：UPDATE / DELETE 的 WHERE 没用上主键或索引列、也没加 LIMIT，服务器就拒绝执行。MySQL Workbench 默认打开这个选项，mysql --safe-updates 也会打开。先把 WHERE 改成按键列定位；确实要整表改，再在本会话临时关掉，改完马上打开。
官方原文
You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column. %s末尾的 %s 是优化器给出的第一条诊断，例如超出 range_optimizer_max_mem_size 或发生了类型转换，说明为什么没用上索引。
出处：MySQL 8.4 Error Reference：Server Error Message Reference 最后核对：
| 错误号 / 符号 | 1175 / ER_UPDATE_WITHOUT_KEY_IN_SAFE_MODE | 出处 |
|---|---|---|
| SQLSTATE | HY000 | 出处 |
| 触发开关 | 会话变量 sql_safe_updates=1 | 出处 |
| 谁会默认打开 | MySQL Workbench 的 Safe Updates 偏好默认开启；mysql --safe-updates（同义 --i-am-a-dummy） | 出处 |
| 不受影响的语句 | EXPLAIN UPDATE / EXPLAIN DELETE 不会报 1175，可以用来查原因 | 出处 |
先确认是谁打开了安全更新模式
1175 只在会话的 sql_safe_updates 为 1 时出现。先在报错的那个连接里查一下当前值，再对照下表找是哪一层打开的：
SELECT @@SESSION.sql_safe_updates AS session_value,
@@GLOBAL.sql_safe_updates AS global_value,
@@SESSION.sql_select_limit AS select_limit,
@@SESSION.max_join_size AS max_join_size;| 你在用 | 怎么打开的 | 怎么确认 |
|---|---|---|
| MySQL Workbench | 偏好里的 Safe Updates (rejects UPDATEs and DELETEs with no restrictions) 默认勾选，连接时把会话设成 1 | Edit → Preferences → SQL Editor，看这一项是否勾选；改完要重新连接才生效 |
mysql 命令行 | 启动时带了 --safe-updates 或 --i-am-a-dummy，或者选项文件 [mysql] 段里写了 safe-updates | 客户端会在连上后执行 SET sql_safe_updates=1, sql_select_limit=1000, max_join_size=1000000;，所以 select_limit 也会变成 1000 |
| 应用 / 连接池 | 连接初始化 SQL 里写了 SET sql_safe_updates=1，或全局值被改成了 1 | global_value 为 1 时新连接默认继承；只有 session_value 为 1 说明是客户端设置的 |
三种改法，按安全程度排序
- 改 WHERE，让它按主键或索引列定位（推荐）。例如先查出要改的主键，再
UPDATE orders SET status='closed' WHERE id IN (...)。这正是安全更新模式想保护的场景：忘写或写错 WHERE 时一次改掉整表。 - 加 `LIMIT`。官方文档允许的写法是
UPDATE tbl_name SET not_key_column=val LIMIT 1;。适合“只改一条/一批”的清理，配合ORDER BY 主键分批执行。 - 只在本会话临时关掉，执行完立刻打开。确认过影响行数再执行，不要在 Workbench 偏好或全局里永久关掉。
-- 先看会影响多少行（只读）
SELECT COUNT(*) FROM orders WHERE created_at < '2025-01-01';
-- 只在当前会话关闭，改完立即恢复
SET SESSION sql_safe_updates = 0;
UPDATE orders SET archived = 1 WHERE created_at < '2025-01-01';
SET SESSION sql_safe_updates = 1;Workbench 里取消勾选 Safe Updates 后要 Query → Reconnect to Server 才生效；只改了偏好不重连，当前标签页仍会报 1175。
WHERE 里有索引列还报 1175：两个官方列出的原因
安全更新模式检查的是优化器最后有没有用上键，不是 WHERE 里有没有写键列。官方文档列出两种“写了键列但没用上”的情况：
| 原因 | 典型写法 | 怎么改 |
|---|---|---|
| 类型转换导致索引失效 | 字符串类型的索引列和数字比较：WHERE c1 = 2222，字符串被转成数字比较，用不上索引 | 按列的类型写常量：WHERE c1 = '2222' |
| 范围扫描超出内存上限 | WHERE id IN (...) 列表很长，范围优化需要的内存超过 range_optimizer_max_mem_size，优化器退回全表扫描 | 把列表拆成几批；或在会话里调大 range_optimizer_max_mem_size |
查原因用 EXPLAIN 加 SHOW WARNINGS：在安全更新模式下 EXPLAIN UPDATE / EXPLAIN DELETE 不会报错，而且 1175 报错末尾的 %s 会带上第一条诊断信息。
EXPLAIN UPDATE orders SET status = 'closed' WHERE order_no = 2222;
SHOW WARNINGS;多表 UPDATE / DELETE 和 SELECT 也会被影响
- 多表 UPDATE / DELETE：只要任意一张目标表走了全表扫描就报 1175。逐张表看
EXPLAIN的 type 列。 - 用
mysql --safe-updates登录时，同时被设置了sql_select_limit=1000和max_join_size=1000000：没写 LIMIT 的 SELECT 最多只返回 1000 行，估算要检查超过 100 万行组合的多表 SELECT 会直接报错。查询结果“少了数据”时先想到这一点。 - 需要别的上限可以在登录时指定：
mysql --safe-updates --select-limit=500 --max-join-size=10000。
如果 UPDATE 不得不扫大范围，执行期间会持有大量行锁，其他会话可能因此等到 1205 锁等待超时。大批量修改建议按主键分批、每批单独提交。
版本说明
本页按 MySQL 8.4 参考手册写，8.0 的 sql_safe_updates、--safe-updates 行为相同。Workbench 的偏好位置以 Workbench 8.0 手册为准。云数据库控制台自带的 SQL 窗口是否默认开启安全更新，以各自文档为准。
常见问题
MySQL 1175 错误是什么意思？
1175（ER_UPDATE_WITHOUT_KEY_IN_SAFE_MODE）表示当前会话开着 sql_safe_updates，UPDATE 或 DELETE 没有用上键列做 WHERE 条件，也没有写 LIMIT，服务器为了防止误改整表而拒绝执行。
MySQL Workbench 报 1175 怎么关闭安全更新？
Edit → Preferences → SQL Editor，取消勾选 Safe Updates，然后 Query → Reconnect to Server 重新连接。更稳妥的做法是不改偏好，只在要执行的语句前后写 SET SESSION sql_safe_updates = 0 / 1。
SET SQL_SAFE_UPDATES = 0 安全吗？
它只影响当前会话，不会改别的连接。风险在于关掉后忘了打开，或者 WHERE 写错一次改了整表。建议先用同样的条件 SELECT COUNT(*) 看行数，执行后立刻 SET SESSION sql_safe_updates = 1。
WHERE 里用了主键还是报 1175？
看是不是发生了类型转换（例如字符串列和数字比较），或者 IN 列表太长超出 range_optimizer_max_mem_size。用 EXPLAIN UPDATE 加 SHOW WARNINGS 看优化器为什么没用索引，报错末尾也会带第一条诊断。
为什么 SELECT 只返回 1000 行？
用 mysql --safe-updates 登录时，客户端同时设置了 sql_select_limit=1000，没写 LIMIT 的 SELECT 最多返回 1000 行。需要更多行就显式写 LIMIT，或登录时用 --select-limit 指定。
下一步
价格以对应页面当前标价为准。
出处（最后核对 2026-11-04）
- MySQL 8.4 Error Reference：Server Error Message Reference
- MySQL 8.4 Reference Manual 6.5.1.6：mysql Client Tips（Using Safe-Updates Mode）
- MySQL Workbench Manual：SQL Editor Preferences（Safe Updates）
- MySQL 8.4 Reference Manual：Server System Variables（sql_safe_updates）
本页摘录并解读上面列出的官方文档，不是官方页面；官方文档更新后以官方为准。本页内容都来自官方文档，没有我们自己的测试结果。