SQL Server合并两张大表的最快方案问询：存在更新，不存在插入

嘿，针对你这种超大规模数据的合并需求，我来分享几个经过生产环境验证的高效方案——毕竟处理千万级数据，速度、资源占用和数据安全性是核心考量。既然你已经能筛选出Table B中需要新增和更新的子集，那我们的优化就从这个子集入手：

前置准备：先把筛选好的数据存进临时表 #

不管用哪种数据库，第一步都建议把筛选后的待处理数据（新增+更新）存入临时表，并给临时表加上用于匹配的主键/唯一索引（比如Identifier + Date，这应该是你的数据唯一标识吧？毕竟同一Identifier可能在不同Date有不同记录）。这么做能避免反复扫描原Table B，大幅提升后续合并的匹配效率。

分数据库的最优实现 #

1. SQL Server 用 MERGE 语句 #

SQL Server的MERGE是专门为这种"插入/更新"场景设计的，语法清晰且效率高，尤其适合已筛选好的数据集：

-- 假设筛选后的数据已经存在于临时表 #Temp_B_Filtered
-- 先给临时表加主键，加速与Table A的匹配
ALTER TABLE #Temp_B_Filtered ADD PRIMARY KEY (Identifier, Date);

SET NOCOUNT ON; -- 减少日志输出，提升速度
SET XACT_ABORT ON; -- 确保事务出错时自动回滚

BEGIN TRANSACTION;
MERGE INTO Table_A AS target
USING #Temp_B_Filtered AS source
ON target.Identifier = source.Identifier AND target.Date = source.Date
WHEN MATCHED THEN
    UPDATE SET 
        IdentifierA = source.IdentifierA,
        IdentifierB = source.IdentifierB,
        DecimalField1 = source.DecimalField1,
        DecimalField2 = source.DecimalField2,
        -- 依次列出其他十进制字段
WHEN NOT MATCHED THEN
    INSERT (Identifier, Date, IdentifierA, IdentifierB, DecimalField1, DecimalField2, ...)
    VALUES (source.Identifier, source.Date, source.IdentifierA, source.IdentifierB, source.DecimalField1, source.DecimalField2, ...);
COMMIT TRANSACTION;

优化点：

• 合并前暂时禁用Table A上的非必要索引（比如查询用的复合索引），合并完成后再重建——索引更新是千万级数据操作的最大性能瓶颈之一。
• 如果筛选后的数据集仍超过500万行，建议分批处理：按Identifier范围或Date区间拆分临时表，每批处理10-50万条，避免单事务过大导致日志暴涨。
• 关闭自动统计信息更新（SET AUTO_UPDATE_STATISTICS OFF），合并完成后再开启。

2. MySQL 用 INSERT ... ON DUPLICATE KEY UPDATE #

MySQL没有原生的MERGE，但INSERT ... ON DUPLICATE KEY UPDATE是替代方案，前提是Table A已经创建了Identifier + Date的唯一索引：

-- 先确保Table A有唯一索引（如果还没的话）
ALTER TABLE Table_A ADD UNIQUE INDEX idx_id_date (Identifier, Date);

-- 临时关闭约束检查，大幅提升速度
SET FOREIGN_KEY_CHECKS = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;

INSERT INTO Table_A (Identifier, Date, IdentifierA, IdentifierB, DecimalField1, ...)
SELECT Identifier, Date, IdentifierA, IdentifierB, DecimalField1, ...
FROM temp_b_filtered
ON DUPLICATE KEY UPDATE
    IdentifierA = VALUES(IdentifierA),
    IdentifierB = VALUES(IdentifierB),
    DecimalField1 = VALUES(DecimalField1),
    -- 其他字段依次更新
;

COMMIT;
-- 恢复约束检查
SET FOREIGN_KEY_CHECKS = 1;
SET UNIQUE_CHECKS = 1;
SET AUTOCOMMIT = 1;

优化点：

• 调大bulk_insert_buffer_size参数（比如设为64M或128M），提升批量插入的缓存能力。
• 同样建议分批处理，避免单次插入数据量过大导致锁表时间过长。

3. PostgreSQL 用 INSERT ... ON CONFLICT DO UPDATE #

PostgreSQL的语法更灵活，ON CONFLICT子句完美适配这种场景，同样需要先创建Identifier + Date的唯一约束：

-- 创建唯一约束
ALTER TABLE Table_A ADD CONSTRAINT uq_table_a_id_date UNIQUE (Identifier, Date);

-- 先把筛选后的数据用COPY导入临时表（比INSERT SELECT快很多）
-- 示例：假设筛选后的数据在本地文件，或者直接用SELECT导入
CREATE TEMP TABLE temp_b_filtered AS SELECT * FROM Table_B WHERE [你的筛选条件];
ALTER TABLE temp_b_filtered ADD PRIMARY KEY (Identifier, Date);

-- 执行合并
INSERT INTO Table_A (Identifier, Date, IdentifierA, IdentifierB, DecimalField1, ...)
SELECT Identifier, Date, IdentifierA, IdentifierB, DecimalField1, ...
FROM temp_b_filtered
ON CONFLICT (Identifier, Date) DO UPDATE SET
    IdentifierA = EXCLUDED.IdentifierA,
    IdentifierB = EXCLUDED.IdentifierB,
    DecimalField1 = EXCLUDED.DecimalField1,
    -- 其他字段依次更新
;

优化点：

• 临时调大maintenance_work_mem和work_mem参数，让数据库分配更多内存用于排序和匹配。
• 合并期间可以临时关闭autovacuum，避免后台清理进程占用资源。

通用超级优化技巧 #

• 业务低峰期执行：千万级数据操作肯定会占用大量CPU、IO资源，尽量选凌晨等业务量最小的时段。
• 先备份再操作：不管方案多成熟，操作前一定要备份Table A，避免数据丢失。
• 测试环境验证：先在测试环境用相同规模的数据集跑一遍，确认速度和数据正确性，再到生产环境执行。

内容的提问来源于stack exchange，提问作者gmn