sql_safe_updates能拦截无安全WHERE的UPDATE/DELETE，因其在服务端解析阶段校验语句结构，仅允许主键或唯一索引的等值条件，不满足则报ERROR 1175，且仅对当前会话生效。
sql_safe_updates 为什么能拦住无WHERE的UPDATE/DELETE
因为它是MySQL服务端原生机制，不是客户端提示或语法检查——只要会话中 sql_safe_updates 设为1，执行时就会在解析阶段校验语句结构。不满足条件（如 WHERE id = 123 中 id 是主键，或带 LIMIT 100）就直接报 ERROR 1175，连执行计划都不生成。
它不依赖你有没有写注释、有没有开事务、有没有备份，也不管你用的是DBeaver还是命令行——只要连接生效，就起作用。
- 仅对当前会话生效，
SET SESSION sql_safe_updates = 1最安全，退出即失效 - 全局设置
SET GLOBAL sql_safe_updates = 1只影响新连接，已有连接不受影响 -
my.cnf中配[mysqld] sql_safe_updates = ON才是永久方案，但需重启MySQL
哪些WHERE条件会被sql_safe_updates拒绝
它认的不是“有没有WHERE”，而是“WHERE里有没有能快速定位单行的列”。普通索引、范围条件、函数包装、子查询全都不算数。
- ✅ 允许：
WHERE order_no = 'OD2026'（order_no有UNIQUE约束） - ✅ 允许：
WHERE id IN (1,2,3)（id是主键） - ❌ 拒绝：
WHERE name = 'Alice'（name只有INDEX，非唯一） - ❌ 拒绝：
WHERE created_at > '2025-01-01'（哪怕created_at是主键，范围条件也不认） - ❌ 拒绝：
WHERE JSON_EXTRACT(data, '$.status') = 'active'（函数导致无法走索引）
为什么开了sql_safe_updates还报1175错误
这不是开关没开，而是你的语句没过它的“安全校验关”。别急着关掉它，先查这三点：
- 确认当前连接是否真生效：
SELECT @@sql_safe_updates返回1才算；用root或带SUPER权限账号登录时，该参数默认被跳过 - 检查
WHERE字段是否确实是主键或唯一索引列：SHOW CREATE TABLE users看KEY和UNIQUE KEY定义 - 确认没用错配置段：在
my.cnf里加safe-updates要放在[mysql]段（客户端），不是[mysqld]段（服务端）
它防不住什么，必须额外补位
sql_safe_updates 名字带“safe”，但防护面极窄。它只管 UPDATE 和 DELETE 的 WHERE 形式，其他高危操作完全不碰。
- ?
DROP TABLE users、TRUNCATE TABLE logs：零拦截，必须靠权限回收，比如REVOKE DROP, TRUNCATE ON *.* FROM 'app_user'@'%' - ?
DELETE FROM t WHERE 1=1：MySQL认为这是合法WHERE，sql_safe_updates不拦 - ? 应用层拼SQL漏条件：ORM里
User::where([])->update(...)生成无WHERE语句，服务端根本收不到 - ? 子查询删除：
DELETE FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'inactive')，即使外层没索引，也照常执行
真正管用的做法，是把 sql_safe_updates 当成第一道过滤网，再叠上权限隔离、客户端拦截规则、SQL审核平台（如Archery）、以及关键表的软删除设计——单独靠它，就像只锁门不关窗。
