delete不加where或条件失效会立刻删光整张表；启用sql_safe_updates=1可强制要求带索引where或limit；delete join必须显式指定目标表别名；执行前务必用select验证逻辑；navicat连生产库须关闭自动提交；只读账号是终极防护。
DELETE 语句没加 WHERE 或条件失效，就会删光整张表——这不是“可能”，而是只要执行就立刻发生。MySQL 默认不回滚，也没后悔键。
开启 sql_safe_updates=1 是最硬核的开关
它不是建议，是强制：只要 UPDATE 或 DELETE 不满足「带索引字段的 WHERE」或「带 LIMIT」，MySQL 就直接报错 ERROR 1175。
-
SET SESSION sql_safe_updates = 1;可在当前连接生效，开发/运维连库第一件事就该执行 - 全局启用要改
my.cnf：[mysqld]下加sql_safe_updates = 1，重启后所有新连接都受控 - 注意：它对
TRUNCATE TABLE和DROP TABLE完全无效，这两类操作靠权限卡死更靠谱 - 常见误判：写了
WHERE id > 0但id是主键 → 合法；写了WHERE msg LIKE '%error%'但msg没索引 → 仍被拦
DELETE JOIN 必须显式指定目标表别名
MySQL 的 DELETE JOIN 语法极易写错，漏掉别名或位置不对，轻则报错，重则删错表。
- 正确写法：
DELETE u FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'cancelled';——u是唯一被删的表 - 错误写法：
DELETE FROM users JOIN orders ...→ 报错ERROR 1064；DELETE users, orders FROM ...→ 真的会删两张表 - 多表删除必须用逗号分隔：
DELETE t1, t2 FROM t1 JOIN t2 ON t1.id = t2.ref_id，但得确认两表都没外键保护，否则删一半就中断 - PostgreSQL / SQL Server 不支持该语法：PG 要用
USING，SQL Server 要写成DELETE t FROM table1 t JOIN table2 s ON ...
执行前一律先用 SELECT 验证逻辑
把 DELETE 换成 SELECT COUNT(*) 和 SELECT *，不是形式主义，是防止逻辑错的最后防线。
-
SELECT COUNT(*) FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'inactive';—— 看数量是否合理（比如预期删 200 行，结果返回 200000） -
SELECT o.id, o.created_at, c.status FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'inactive' LIMIT 5;—— 确认实际数据符合业务语义 - 时间字段别裸写
'2025-01-01'，统一用STR_TO_DATE('2025-01-01', '%Y-%m-%d')或补全为'2025-01-01 00:00:00'，避免隐式转换导致索引失效 -
JOIN字段和WHERE字段都得有索引，否则EXPLAIN一看就是type: ALL，大表下锁表几十秒起步
Navicat 连生产库必须关自动提交
Navicat 默认 AUTOCOMMIT=1，意味着每条 DELETE 执行完就落盘，没有 Ctrl+Z。
- 连库后第一件事：
SET AUTOCOMMIT = 0;，之后所有DELETE/UPDATE都可ROLLBACK - 配合
sql_safe_updates=1+SELECT验证，形成三层防护：语法拦、逻辑验、事务兜底 - 切记：多个标签页之间容易粘贴错连接，生产连接建议单独建连接配置，名字标清楚 “PROD-READONLY” 或 “PROD-WRITE-NO-AUTO”
- 只读账号才是终极保险：
GRANT SELECT ON mydb.* TO 'reporter'@'%';，连删语句都发不出去
真正危险的不是不会写 DELETE，而是以为加了 WHERE 就安全——字段没索引、条件恒真、JOIN 写反、时间格式隐式转换，都会让那条 WHERE 形同虚设。防误删的关键不在技巧多，而在每一步都有确定性反馈。
