sql_safe_updates仅防无条件delete/update，要求where含主键或唯一索引等值条件，不防drop/truncate等ddl；需权限隔离、客户端拦截、审计日志与软删除组合防护。
开启 SQL_SAFE_UPDATES 是最直接有效的防误删手段，但它不是万能开关——它只拦得住 DELETE 和 UPDATE，对 DROP TABLE、TRUNCATE TABLE 完全无效。
为什么 SET SQL_SAFE_UPDATES = 1 后还报错 1175
错误 ERROR 1175 不代表设置失败，而是语句没通过安全模式的“有效性校验”：
-
WHERE必须包含主键（PRIMARY KEY）或唯一索引列（UNIQUE KEY）的等值条件，比如WHERE id = 123或WHERE email = 'a@b.com' -
WHERE name = 'alice'即使name有普通索引，也会被拦截——非唯一索引不满足规则 -
WHERE created_at > '2024-01-01'这类范围条件，哪怕created_at是主键，也不被认可 - 显式加
LIMIT可绕过（如UPDATE t SET x=1 WHERE y=2 LIMIT 100），但仅限于 MySQL 客户端行为，不改变语义风险
全局启用与会话级启用的区别
两者作用域和持久性完全不同：
- 会话级：执行
SET SQL_SAFE_UPDATES = 1;，只影响当前连接，关闭终端即失效 - 全局级：
SET GLOBAL SQL_SAFE_UPDATES = 1;，影响所有新建立的连接，但数据库重启后丢失 - 永久生效：必须在
my.cnf的[mysqld]段添加sql_safe_updates=ON，然后重启 MySQL；或用init-file方式加载初始化 SQL（如init-file=/opt/init.sql，文件内写SET GLOBAL SQL_SAFE_UPDATES = 1;）
它防不住哪些操作——别被名字误导
SQL_SAFE_UPDATES 名字带“safe”，但实际防护面很窄：
- 完全不拦截
DROP TABLE、TRUNCATE TABLE、ALTER TABLE ... DROP COLUMN等 DDL 语句——触发器也监听不到这些 - 对
DELETE FROM t;有效，但对DELETE FROM t WHERE 1=1;无效（MySQL 认为这是合法 WHERE） - 不校验
WHERE条件是否真能命中数据：你写WHERE id = 999999999，只要语法合规就放行，哪怕实际删 0 行 - 无法防止应用层拼接 SQL 时漏掉条件，比如 ORM 中
User::where([])->delete()在某些配置下可能生成无条件语句
真正管用的组合策略
单靠一个开关解决不了生产误删问题，得叠加控制层：
- 权限隔离：对业务账号执行
REVOKE DROP, TRUNCATE ON *.* FROM 'app_user'@'%';，确认SHOW GRANTS输出里没有DROP - 客户端强制：在 MySQL Shell / DBeaver / Navicat 等工具中配置命令拦截规则，输入
DELETE或DROP时弹出工单号输入框 - 审计兜底：开启
general_log并写入表（log_output = 'TABLE'），用脚本定时扫描mysql.general_log，匹配DROP TABLE、DELETE FROM \w+;$（结尾无 WHERE）等高危模式，立即告警 +KILL - 软删除兜底：核心表加
is_deleted TINYINT DEFAULT 0字段，业务逻辑统一走UPDATE ... SET is_deleted = 1，物理删除由归档任务异步执行
最常被忽略的一点：安全更新模式只检查语法结构，不理解业务意图。你写了 WHERE status = 'pending'，它不管这个 status 是不是全表都 pending——最终删多少行，还是得靠你提前 SELECT COUNT(*) 验证。
