MySQL中DELETE JOIN必须显式指定目标表别名，如DELETE u FROM users u JOIN orders o ON u.id = o.user_id；不可省略别名或误写为DELETE users, orders FROM...，多表删除需用DELETE t1, t2 FROM t1 JOIN t2 ON...，且须确保无外键阻断；PostgreSQL和SQL Server不支持该语法；执行前务必用SELECT验证逻辑、检查索引及执行计划。

DELETE JOIN必须显式指定目标表别名

MySQL不支持DELETE FROM t1 JOIN t2这种写法，直接执行会报错ERROR 1064。你必须明确写出要删哪张表，比如DELETE u FROM users u JOIN orders o ON u.id = o.user_id——这里u是唯一被删的目标，o只是用来过滤的关联表。

常见错误是漏掉目标表标识，或误写成DELETE users, orders FROM ...，结果可能同时删两表，而若orders有子表（如order_items）且没设ON DELETE CASCADE，就会中断报错，但部分数据已删，事务不完整。

• 只删一张表时，目标别名必须出现在DELETE后，且不能在JOIN条件右侧作为被关联方参与逻辑（例如DELETE o FROM orders o JOIN users u ON u.id = o.user_id合法；但DELETE u FROM users u JOIN orders o ON o.user_id = u.id虽语法通过，逻辑上却让u成了被动匹配方，易混淆）
• 想删多张表，得用逗号分隔：DELETE t1, t2 FROM t1 JOIN t2 ON t1.id = t2.ref_id，但必须确认两表都允许被删，且无外键保护阻断
• PostgreSQL和SQL Server根本不认这种语法：PG必须用USING，SQL Server要用DELETE t FROM t JOIN s ON ...，别名t必须紧贴DELETE后面

先用SELECT验证WHERE和JOIN逻辑

DELETE JOIN的WHERE条件一旦写错，影响行数可能远超预期。比如本想删“30天前未支付订单”，却漏了status = 'unpaid'，结果把所有历史订单全匹配上了。

执行前务必把DELETE换成SELECT COUNT(*)和SELECT *各跑一遍：

• SELECT COUNT(*) FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'inactive'——看数量是否合理
• 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'，避免隐式转换导致索引失效

ON和WHERE字段必须有索引，否则性能崩坏

JOIN字段（如orders.customer_id）和WHERE字段（如customers.status）若没索引，MySQL会走全表扫描+嵌套循环，大表下可能锁表几十秒，甚至触发max_join_size限制直接报错。

执行前查执行计划：EXPLAIN SELECT ...（用同条件的SELECT模拟），确认type是ref或range，key列显示用了哪个索引。

• 复合索引要注意最左前缀：如果WHERE里用status = 'inactive' AND created_at ，索引应建为<code>(status, created_at)，而不是反过来
• NOT EXISTS比LEFT JOIN更安全，尤其当关联表存在一对多关系时，LEFT JOIN ... IS NULL可能因重复行导致误判，而NOT EXISTS天然规避该问题
• 别在子查询里用SELECT *，写SELECT 1即可，优化器更容易识别为半连接

生产环境必须开SQL_SAFE_UPDATES + 手动事务

Navicat连生产库后，图形界面的“自动提交开关”不可靠，且不同版本位置不一致。真正有效的控制是SQL命令：

• 新标签页第一行必须是：SET AUTOCOMMIT = 0;——关掉自动提交，给回滚留机会
• 紧接着加：SET SQL_SAFE_UPDATES = 1;——它会拦截无WHERE、或WHERE没用到索引的DELETE/UPDATE
• 执行完DELETE后，立刻查SELECT ROW_COUNT();，确认影响行数与预估一致；不一致就立刻ROLLBACK;
• 别依赖触发器兜底：SIGNAL SQLSTATE '45000'能拦DELETE，但拦不住TRUNCATE或跨库操作，且有级联外键的表根本建不了BEFORE DELETE触发器

软删除和分批删不是可选项，是降低风险的实际手段——尤其对订单、日志这类关键数据，硬删前先评估是否真需要物理清除；大表批量删时，LIMIT不是安全阀，而是锁表风险放大器，优先用主键范围分片（如WHERE id BETWEEN 10000 AND 20000）更可控。