DELETE WHERE EXISTS最安全，必须用相关子查询（如customers.id = orders.customer_id）绑定主表与子表，避免误删；先SELECT预查，再事务+LIMIT分批执行，并确保关联字段有索引。
DELETE WHERE EXISTS 用法最安全
直接用 DELETE 关联另一张表时，不能写 JOIN（MySQL 8.0+ 虽支持但语法特殊，易出错），EXISTS 是跨数据库兼容、语义清晰、执行计划可控的首选。
常见错误是写成 DELETE FROM t1 JOIN t2 ON ...，在 PostgreSQL 或 SQL Server 会报语法错误；即使 MySQL 允许，也容易误删整张表——因为没加 WHERE 条件或子查询漏了相关性。
正确写法是把“另一张表”的筛选逻辑放进 EXISTS 子查询里，并确保子查询中引用主表字段（即“相关子查询”）：
DELETE FROM orders
WHERE EXISTS (
SELECT 1 FROM customers
WHERE customers.id = orders.customer_id
AND customers.status = 'inactive'
);-
SELECT 1是惯例，比SELECT *更轻量，不影响逻辑 - 子查询里的
customers.id = orders.customer_id是关键：它把子查询和外层orders行绑定，避免全表误删 - 先用
SELECT * FROM orders WHERE EXISTS (...)预查要删哪些行，确认无误再执行DELETE
MySQL 中用 JOIN DELETE 要加别名
MySQL 允许 DELETE t1 FROM t1 JOIN t2 语法，但它不是标准 SQL，且极易因别名缺失导致意外清空。
典型翻车场景：忘记给被删表起别名，或 JOIN 条件写错，结果删掉 t1 全表：
DELETE FROM orders JOIN customers ON orders.customer_id = customers.id WHERE customers.status = 'inactive';
这段在 MySQL 会报错，因为没指定删哪张表的别名。必须显式声明：
DELETE o FROM orders AS o JOIN customers AS c ON o.customer_id = c.id WHERE c.status = 'inactive';
- 必须用
DELETE o FROM orders AS o明确目标表别名 -
JOIN后不能跟USING或复杂表达式，条件尽量保持简单可读 - 该写法在 PostgreSQL / SQLite / SQL Server 中完全不支持，换库即失效
WHERE IN 子查询有 NULL 和性能陷阱
用 WHERE id IN (SELECT ...) 看似直观，但有两个硬伤：子查询结果含 NULL 会导致整条 IN 判断为 UNKNOWN，最终不删任何数据；另外大结果集可能触发临时表或全表扫描。
例如：
DELETE FROM orders WHERE customer_id IN ( SELECT id FROM customers WHERE status = 'inactive' );
如果 customers.id 允许为 NULL，且恰好有 NULL 值匹配，这条语句就静默失效——既不报错，也不删数据。
- 强制排除
NULL：SELECT id FROM customers WHERE status = 'inactive' AND id IS NOT NULL - 当子查询返回上万行时，
IN效率远低于EXISTS，尤其在customer_id没索引时 - PostgreSQL 对
IN子查询有行数限制（默认 10000），超限直接报错
事务 + LIMIT 防误操作是上线前必做动作
无论用哪种方式，生产环境执行前必须套事务，并控制单次删除量。直接跑全量 DELETE 没有后悔药。
安全操作节奏：
BEGIN;
DELETE FROM orders
WHERE EXISTS (
SELECT 1 FROM customers
WHERE customers.id = orders.customer_id
AND customers.status = 'inactive'
)
LIMIT 1000;
SELECT ROW_COUNT(); -- 看删了几行
-- 确认无误再 COMMIT，否则 ROLLBACK-
LIMIT不是所有数据库都支持（PostgreSQL 需用WITH t AS (...) DELETE ...实现分批） - MySQL 的
ROW_COUNT()返回上一条语句影响行数，务必在COMMIT前查 - 即使加了
LIMIT，也要检查orders.customer_id是否有索引——没索引时每次都要扫全表
最常被跳过的其实是索引验证：删 10 万行慢，往往不是语句问题，而是 customer_id 字段没建索引，导致 EXISTS 内部每次都要全表扫 customers。
