能，但仅限单向只插入场景；它通过子查询WHERE过滤源表，用NOT EXISTS等避免重复插入，无法更新或删除，不保证镜像一致，适合补数或ETL初载。
INSERT INTO SELECT 能不能直接带条件同步？
能，但仅限于「单向、只插入、不更新不删除」的简单同步场景。它本质是数据搬运，不是真正的「同步」——INSERT INTO SELECT 不会自动识别目标表已有数据，重复执行会导致主键冲突或重复记录。
WHERE 条件写在子查询里，不是 INSERT 后面
常见错误是把 WHERE 写在 INSERT INTO ... SELECT 语句末尾，比如：INSERT INTO t2 SELECT * FROM t1 WHERE id > 100 —— 这语法合法，但只过滤源表；若想避免插入已存在的记录，必须用 NOT EXISTS 或 LEFT JOIN 在子查询中排除。
-
INSERT INTO t2 (id, name) SELECT s.id, s.name FROM source_table s WHERE s.status = 'active'：只选活跃数据，但不管 t2 里有没有 -
INSERT INTO t2 (id, name) SELECT s.id, s.name FROM source_table s WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE t2.id = s.id)：这才是带「存在性条件」的同步 - 如果目标表有自增主键，别漏掉
SET IDENTITY_INSERT t2 ON（执行前）和OFF（执行后），否则报错Cannot insert explicit value for identity column
和 MERGE 相比，INSERT INTO SELECT 的硬伤
它无法在一个语句里同时处理「插入新行 + 更新旧行 + 删除多余行」。比如源表删了一条记录，INSERT INTO SELECT 完全无感知；目标表某行被人工改过，它也不会回滚或覆盖。
- 适合场景：定时补数、ETL 初次加载、日志归档到历史表
- 不适合场景：要求目标表与源表严格镜像一致（如主数据分发）、需事务级一致性保障
- 性能上，大批量插入时比
MERGE更快，因为没匹配开销；但缺少原子性控制，出错后得靠外部逻辑清理脏数据
容易被忽略的权限与锁问题
执行 INSERT INTO SELECT 需要同时拥有源表的 SELECT 权限和目标表的 INSERT 权限。跨库操作时，若目标库不是当前 USE 库，必须显式写成 targetdb.schema.table，否则报错 Invalid object name。
- 长事务下，源表会被加共享锁（S 锁），可能阻塞其他
UPDATE；目标表加排他锁（X 锁），阻塞读写 - 若同步量大，建议加
OPTION (MAXDOP 1)避免并行计划引发额外锁升级 - 不要在生产高峰期跑全表
INSERT INTO SELECT，尤其没WHERE条件时——它会锁死整个目标表
实际做跨表同步，光靠 INSERT INTO SELECT 很难闭环。真正需要「带条件同步」，大概率得切到 MERGE 或事务包装的存储过程，否则总有一类变更漏掉。
