开启 sql_safe_updates 是最直接的防误删手段，但仅限 UPDATE/DELETE 且需会话级设置生效；真正兜底靠权限隔离、SQL 审核与 binlog 回滚。
开启 sql_safe_updates 是最直接、成本最低的防误删手段，但它只拦 UPDATE/DELETE，不拦 DROP/TRUNCATE；真正兜底靠的是权限隔离 + SQL 审核 + binlog 回滚能力。
为什么 sql_safe_updates=1 有时不生效
这个参数是会话级的，不是全局开关。你用 SET GLOBAL sql_safe_updates = 1 设置后，新连接不会继承——除非配置了 init_connect 或客户端显式带参连接。
- 写在
[mysql]或[client]段（如safe-updates）只对原生命令行mysql生效，Navicat、DBeaver、JDBC 等工具默认忽略 - 写在
[mysqld]段直接报错：“Unknown variable 'sql_safe_updates'”，MySQL 不认这个写法 - 正确永久方案：在
[mysqld]段加init_connect='SET sql_safe_updates=1;'，再配合SET GLOBAL sql_safe_updates = 1（需 SUPER 权限）加固 root 会话 - 验证是否真生效：连上后执行
SELECT @@sql_safe_updates;，返回1才算到位；断开重连再查一次，确认没回退
DELETE 报错 ERROR 1175 的真实原因
不是“只要有 WHERE 就行”，而是 WHERE 必须能命中索引（主键、唯一键、普通索引均可），否则仍被拦截。比如 DELETE FROM logs WHERE msg LIKE '%error%';，若 msg 无索引，照样报错。
- 常见误判：WHERE 用了字段但没建索引 → 需先
ALTER TABLE logs ADD INDEX idx_msg (msg); - 临时绕过：加
LIMIT（如DELETE FROM logs WHERE msg LIKE '%error%' LIMIT 1000;），但仅限调试，上线必须删掉 - 恒真条件如
WHERE 1=1或WHERE id > 0（id 是主键）可过，因为 MySQL 能识别其等价于全表扫描但“有索引参与” -
TRUNCATE TABLE完全不受影响——它不走 DML 流程，所以权限和 safe_updates 都拦不住，必须靠DROP权限控制
SQL 审核工具怎么拦住危险语句
审核不是看语法，而是分析执行意图。像 soar 或 archer 会静态解析 SQL，识别出“无 WHERE 的 DELETE”或 “WHERE 字段未索引”这类模式，并阻断上线。
- 必须把审核嵌入 CI/CD 流程，而不是人工点按钮。例如 GitLab CI 中跑
soar -query "$(cat delete.sql)" -report-type=json，返回非零即失败 - 规则要自定义：默认规则可能放过
DELETE FROM t WHERE status = 'old'，但如果status列没有索引，就得加一条“WHERE 字段必须在索引中”的检查项 - 注意边界：应用层拼接的动态 SQL（如 MyBatis 的
<if test="xxx"></if>）可能绕过审核，得靠运行时审计（如 MySQL Enterprise Audit Plugin）补漏 - 审核不能替代权限。就算审核放行了
DELETE FROM users WHERE id IN (SELECT ...)，如果账号没DELETE权限，照样执行不了
权限最小化到底要卡到哪一层
不是“只给 SELECT”，而是按动作卡：一个订单导出脚本只需要 SELECT 权限，但一个定时归档任务可能需要 DELETE，只是限定在 logs 表且只能删 30 天前数据。
- 禁止
GRANT ALL ON *.*，哪怕只给测试账号；新建账号后第一件事是REVOKE DROP, ALTER, CREATE, FILE, PROCESS, SUPER ON *.* FROM 'user'@'%'; - MySQL 8.0+ 用角色更清晰：
CREATE ROLE 'archiver'; GRANT DELETE ON mydb.logs TO 'archiver'; GRANT 'archiver' TO 'job_user'@'%'; - 关键表（如
users,orders）加软删除字段is_deleted TINYINT DEFAULT 0，业务代码改用UPDATE SET is_deleted = 1，物理删除只由 DBA 在低峰期执行 - 最容易被忽略的是备份账号和监控账号：它们只要
SELECT+LOCK TABLES+REPLICATION CLIENT，绝不该有UPDATE权限，否则备份脚本出 bug 可能反向污染生产库
真正难防的不是手抖打错 WHERE，而是脚本里硬编码了高权账号、定时任务连错环境、或者 binlog_format 被设成 STATEMENT 导致闪回失败——这些细节比开不开 safe-updates 更决定生死。
