sql_safe_updates是最直接防误删手段，但仅限UPDATE/DELETE且需WHERE走索引或带LIMIT；不生效因是会话级设置，新连接不继承，须配init_connect+GLOBAL设置并验证@@sql_safe_updates=1。
开启 sql_safe_updates 是最直接有效的防误删手段，但它只对 UPDATE 和 DELETE 生效，且必须满足“WHERE 条件能走索引”或带 LIMIT，否则照样报错 ERROR 1175。
为什么 sql_safe_updates=1 有时不生效
它不是全局开关，而是会话级设置。你执行 SET GLOBAL sql_safe_updates = 1 后，新连接不会自动继承——除非配置了 init_connect 或客户端显式带参连接。
-
my.cnf中写在[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 和 DROP TABLE 完全不受影响
sql_safe_updates 对这两类语句完全无效，因为它们不走 DML 流程，也不依赖 WHERE。真正能拦住它们的只有权限控制。
-
TRUNCATE TABLE不记 binlog 的DELETE事件，不可回滚，必须靠DROP权限限制账号能否执行 - 生产环境账号不应拥有
DROP、ALTER权限；DBA 账号应单独管理，且登录需跳板机 + OTP - 应用连接池配置中，显式使用只读账号（仅
GRANT SELECT），而非复用高权账号
真正兜底不是靠一个开关，而是组合策略：sql_safe_updates 拦住最常见的无条件 DELETE/UPDATE，权限最小化卡死 TRUNCATE/DROP，SQL 审核工具（如 soar）提前识别“WHERE 字段未索引”，再加上 binlog + 备份演练确保事后可逆——这些环节里，最容易被忽略的是 init_connect 配置是否真生效，以及开发账号是否真的没被悄悄授予 DROP 权限。
