INSERT … SELECT + WHERE NOT EXISTS 是MySQL中实现条件插入、避免重复的核心方案：通过子查询检查目标表是否存在匹配记录，仅当NOT EXISTS为TRUE时才执行插入，从而在单语句中完成存在性判断与写入，兼顾简洁性与原子性。
INSERT ... SELECT + EXISTS 是最直接的防重插入方案
想避免重复插入，又不想先查再插（防止并发冲突），就得用原子性操作。核心思路是让数据库自己判断是否存在，存在就不插——INSERT ... SELECT 配合 EXISTS 子查询刚好满足这个需求。
典型写法是把要插入的数据构造成一行或子查询结果，再用 WHERE NOT EXISTS 过滤：
INSERT INTO users (id, name, email) SELECT 1001, 'Alice', 'alice@example.com' WHERE NOT EXISTS ( SELECT 1 FROM users WHERE email = 'alice@example.com' );
-
SELECT后面不能加FROM表（除非你真要从某表取值），这里用的是“无源行构造”，兼容 MySQL、PostgreSQL、SQL Server - MySQL 8.0+ 和 PostgreSQL 支持
VALUES表达式，可写成VALUES (1001, 'Alice', 'alice@example.com')替代SELECT，语义更清晰 - 注意
NOT EXISTS中的子查询必须关联外层逻辑（比如用email字段比对），否则可能误判——不关联就变成“只要表里有任意一条记录，整个插入就被拦住”
唯一索引 + INSERT IGNORE / ON CONFLICT 才真正防并发冲突
EXISTS 方案在高并发下仍有风险：两个事务几乎同时执行 NOT EXISTS 判断，都得到“不存在”，然后都插入成功。真正可靠的防重，必须依赖唯一约束和数据库的冲突处理机制。
- 先确保目标字段有唯一索引：
CREATE UNIQUE INDEX idx_users_email ON users(email); - MySQL 用
INSERT IGNORE：冲突时静默跳过，不报错但ROW_COUNT()返回 0 - PostgreSQL 用
ON CONFLICT DO NOTHING：语法更明确，支持指定冲突字段和动作 - SQL Server 用
MERGE或带IF NOT EXISTS的事务块，但MERGE有已知死锁风险，慎用
单纯靠 EXISTS 判断，只是逻辑层面“尽力而为”，不是并发安全的解决方案。
EXISTS 子查询里的字段别名容易引发隐式错误
当 EXISTS 子查询引用了外部表字段，又没加表别名或限定，SQL 解析器可能误绑到子查询内层表，导致逻辑错乱或全表扫描。
- 错误写法：
WHERE NOT EXISTS (SELECT 1 FROM logs WHERE user_id = id)—— 如果logs表也有id字段，这里的id可能被解析为logs.id而非外部users.id - 正确写法：给外部表加别名，如
INSERT INTO users u SELECT ... WHERE NOT EXISTS (SELECT 1 FROM logs l WHERE l.user_id = u.id) - PostgreSQL 对未限定列更严格，会直接报错；MySQL 则可能静默绑定错，排查困难
批量插入时 EXISTS 效率骤降，优先考虑临时表 + LEFT JOIN
一次插 100 条，还对每条都跑一遍 NOT EXISTS 子查询？那等于执行 100 次独立查询，IO 和执行计划开销翻倍。这时候该换策略。
- 把待插入数据先
INSERT INTO temp_staging（临时表），再用LEFT JOIN筛出真正需要插入的记录 - 示例：
INSERT INTO users SELECT s.* FROM temp_staging s LEFT JOIN users u ON s.email = u.email WHERE u.email IS NULL; - 临时表记得建索引（尤其关联字段），否则
JOIN会变全表扫描 - MySQL 不支持 CTE 递归或复杂
WITH插入，PostgreSQL 可用WITH data AS (...) INSERT ... SELECT ... FROM data LEFT JOIN ...保持语句内聚
单条插入用 EXISTS 简洁，批量场景下它就成了性能陷阱——不是语法错，是执行路径错了。
