sql_safe_updates=1 是最轻量有效的防线，但仅拦截无where或where未走主键/唯一索引的语句，无法防范逻辑错误；必须全局启用，java应用需连接后立即执行set，且需验证where是否真走索引、避免隐式转换、结合count和样本核查、加dry run、禁用truncate、最小化权限并设触发器兜底。
直接启用 SQL_SAFE_UPDATES=1 是最有效、最轻量的防线，但它只拦得住“没WHERE”或“WHERE没走索引”的语句，拦不住逻辑写错的条件——这点必须提前认清。
为什么 SQL_SAFE_UPDATES=1 必须全局启用
它不是可选功能，而是 MySQL 内置的安全开关：开启后，所有 DELETE 和 UPDATE 必须满足「带 WHERE 且该条件命中主键/唯一索引」或「带 LIMIT」，否则直接报错 ERROR 1175 (HY000): You are using safe update mode...。
- 服务端配置
safe-updates（注意不是sql_safe_updates）只影响mysql命令行客户端，对 JDBC、PyMySQL、Node.js mysql2 等驱动完全无效 - Java 应用必须在连接建立后立即执行
SET SQL_SAFE_UPDATES = 1，不能依赖配置文件 - MySQL 8.0+ 推荐在
my.cnf的[mysql]段落加init-command="SET SQL_SAFE_UPDATES=1"，确保所有命令行会话默认生效
WHERE 条件写了也不安全？检查这三件事
写了 WHERE 不等于安全。MySQL 判定是否“可执行”的依据是执行计划，不是语法是否含 WHERE 关键字。
- 用
EXPLAIN DELETE FROM users WHERE name = 'alice'查看type字段：要是ALL或index，说明全表扫描，SQL_SAFE_UPDATES=1会拒绝执行 -
name字段必须是主键或有唯一索引；普通二级索引（如INDEX(name)）不满足“安全模式”要求 - 隐式类型转换会失效索引：比如
WHERE id = '123'（id 是INT），MySQL 自动转成数字比较，但某些版本下仍可能不走索引，建议统一用WHERE id = 123
开发阶段怎么验证 DELETE 是真安全
别信自己写的 WHERE，要靠数据说话。
- 先跑
SELECT COUNT(*) FROM table WHERE ...，确认数量级是否合理（比如预期删 10 行，结果返回 50 万，立刻停手） - 再查样本：
SELECT * FROM table WHERE ... ORDER BY id DESC LIMIT 5，人工核对是否真为待删数据 - 高风险操作加 Dry Run 开关：代码里控制是否真正执行
executeUpdate()，只打印 SQL 和参数，日志留痕 - 禁止使用恒真条件：
WHERE 1=1、WHERE status != ?（当 ? 为NULL时可能匹配全部）
生产环境不能只靠人盯，得有自动兜底
人工流程总有疏漏，关键表必须加硬性约束。
- 给核心表（如
users、orders）加BEFORE DELETE触发器，限制单次最多删 100 行：IF (SELECT COUNT(*) FROM OLD_TABLE) > 100 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Too many rows to delete'; END IF; -
TRUNCATE不走触发器、不记 binlog、不可回滚，必须单独禁用：REVOKE TRUNCATE ON db.* FROM 'app'@'%'; - 应用账号权限最小化：只授
INSERT, SELECT, UPDATE，DELETE权限按需临时开通，且仅限特定表
真正容易被忽略的点是：SQL_SAFE_UPDATES 对 ORDER BY + LIMIT 组合不校验排序字段是否索引——DELETE FROM logs WHERE created_at 看似可控，但如果 <code>created_at 没索引，照样被拦；而如果加了索引但 ORDER BY id 没索引，MySQL 可能排序慢到锁表，这时安全模式反而成了障眼法。
