NOT EXISTS在INSERT SELECT中易失效，因子查询未关联外层表、关联字段无索引或类型不一致，导致全插或全跳；正确写法需相关子查询、索引支持及类型严格匹配。
直接用 NOT EXISTS 做插入前过滤是可行的，但必须满足三个硬性条件：子查询要相关、关联字段有索引、类型严格一致；否则要么全插、要么全跳，根本起不到“去重插入”作用。
为什么NOT EXISTS在INSERT SELECT里容易失效
最常见的错误是写成这样：
INSERT INTO orders (order_id, amount) SELECT s.order_id, s.amount FROM staging_orders s WHERE NOT EXISTS (SELECT 1 FROM orders);
这个子查询没引用外层表字段，导致它和 s 行完全无关。数据库会先执行一次 SELECT 1 FROM orders：如果 orders 非空，结果恒为 FALSE，所有行都被跳过；如果 orders 刚好为空，结果恒为 TRUE，所有行全插——这已经不是“去重”，而是“开关式插入”。
- 子查询必须包含类似
t.order_id = s.order_id的显式关联条件 - 关联字段（如
order_id）在目标表上必须有索引，否则每次判断都触发全表扫描 - 两个表中对应字段类型要兼容，比如
VARCHAR(32)和CHAR(32)在某些数据库里隐式转换会导致索引失效
NOT EXISTS 插入语句的正确写法与参数细节
标准结构是主表（源）驱动，子查询（目标）做存在性检查。例如从临时表补漏到主订单表：
INSERT INTO orders (order_id, customer_id, amount, created_at) SELECT s.order_id, s.customer_id, s.amount, s.created_at FROM staging_orders s WHERE NOT EXISTS ( SELECT 1 FROM orders t WHERE t.order_id = s.order_id );
-
SELECT 1是惯例，比SELECT *或SELECT COUNT(*)更轻量，优化器不关心具体列 - 如果业务唯一键是复合的（如
(customer_id, order_date)），WHERE条件里必须全部写出，缺一不可 - MySQL 8.0+ 和 PostgreSQL 能较好地将这种结构优化为
ANTI JOIN；SQL Server 需确认执行计划里出现NESTED LOOPS ANTI或HASH MATCH ANTI - PostgreSQL 中若子查询加了
ORDER BY或LIMIT，可能阻止优化器展开子查询，应删除
对比 INSERT IGNORE 和 ON CONFLICT DO NOTHING
NOT EXISTS 不是万能替代品。它的优势在于不要求目标表有唯一约束，适合脏数据迁移或补数场景；劣势是无法利用唯一索引的快速查找能力，性能通常弱于冲突语法。
-
INSERT IGNORE（MySQL）要求目标表有PRIMARY KEY或UNIQUE约束，否则报错；且对违反约束的行静默跳过，不报错也不提示 -
ON CONFLICT DO NOTHING（PostgreSQL）同样依赖唯一约束，但可指定冲突目标（如ON CONFLICT (order_id) DO NOTHING），更精准 - 当目标表无主键/唯一索引时，
NOT EXISTS是唯一安全选择；但务必确保子查询关联字段已建索引，否则大表插入会慢到超时 - 如果源表本身有重复
order_id，NOT EXISTS仍会逐行检查并插入所有不冲突的行，而INSERT IGNORE可能因唯一键冲突批量跳过
真正卡住性能的往往不是语法写法，而是子查询里那个 WHERE 字段有没有索引——没有索引的 NOT EXISTS 在十万行以上就明显变慢，且优化器很难自动挽救。
