Azure Synapse专用SQL池大表MERGE操作性能优化咨询

现有方案性能骤降的核心原因 #

你当前测试场景性能异常，是代码逻辑错误、架构适配不到位、实现方式不符合MPP引擎特性共同导致的：

• 独立UPDATE语句存在逻辑bug：你写的UPDATE tgt SET tgt.A = src.A WHERE EXISTS(SELECT B FROM tgt WHERE tgt.B = src.B)没有在UPDATE层直接关联两表的匹配键，执行时会生成tgt和src的笛卡尔积。1000条小数据量下计算量低感知不明显，数据量涨到几十万级后计算量指数级上升，不仅跑不完，就算跑完结果也是错的——tgt所有行的A值都会被随机更新。
• MERGE语句不适合Synapse专用SQL池大表场景：MPP架构下MERGE会触发表级锁、生成大量冗余事务日志，若两表分布不对齐还会触发全节点数据跨节点搬运（Shuffle Move），IO开销极高，官方从来没把MERGE作为亿级表Upsert的推荐方案。
• 临时表配置不匹配：你提到src是存储过程内临时创建的表，如果默认用ROUND_ROBIN轮询分布，和持久化tgt表的分布策略不一致，关联时必须跨节点传输全量数据，性能会差一个数量级。
• 未利用Synapse最小日志写入特性：直接逐行执行UPDATE、INSERT操作会触发全量事务日志，写入速度被日志IO限制。

最优实现方案（亿级表场景官方推荐模式） #

基于CTAS（CREATE TABLE AS SELECT）的元数据切换方案，比MERGE、原生INSERT/UPDATE快5~10倍，2亿tgt表+百万级src增量的场景通常10分钟内可完成，且结果一致性有保障：

步骤1：创建临时src表时对齐tgt的分布策略 #

不要用默认建表配置，关联键B必须和tgt保持相同的分布规则，从根源避免跨节点数据移动：

CREATE TABLE src
WITH (
    DISTRIBUTION = HASH(B), -- 和tgt的分布列完全一致，如果tgt本身按B哈希分布直接对齐即可
    HEAP -- 临时写入表用堆表，写入速度远快于带索引的表
)
AS
-- 替换为你原有的src表数据灌入逻辑
SELECT A, B FROM 你的数据源;

步骤2：CTAS一次性计算合并后的全量结果 #

CTAS是Synapse专用SQL池中并行度最高、日志量最小的批量写入操作，一次计算同时覆盖「更新匹配行、插入新行」两个逻辑，避免多次扫描tgt表：

CREATE TABLE tgt_tmp
WITH (
    DISTRIBUTION = HASH(B), -- 和tgt分布规则完全一致
    CLUSTERED COLUMNSTORE INDEX, -- 和tgt的索引配置保持一致
    -- 如果tgt有分区配置，这里和tgt分区规则完全对齐
)
AS
-- 取tgt中不需要更新的存量记录
SELECT tgt.A, tgt.B
FROM tgt
LEFT ANTI JOIN src
ON tgt.B = src.B
UNION ALL
-- 取src中所有最新记录（包含需要更新到tgt的匹配行、tgt不存在的新增行）
SELECT src.A, src.B
FROM src;

步骤3：元数据切换替换原tgt表 #

表重命名是纯元数据操作，秒级完成，无业务中断：

DROP TABLE tgt;
RENAME OBJECT tgt_tmp TO tgt;
-- 清理临时表
DROP TABLE src;
-- 如果tgt上有权限配置、统计信息，切换后重新补建即可，成本极低

可落地的补充优化手段 #

• 如果坚持用拆分INSERT/UPDATE的模式，必须修正UPDATE写法，避免笛卡尔积，同时加过滤条件减少无效写入：

-- 正确的增量插入逻辑
INSERT INTO tgt
SELECT A,B FROM src
WHERE NOT EXISTS (SELECT 1 FROM tgt WHERE tgt.B = src.B);

-- 正确的更新逻辑，直接关联两表，只更新值确实发生变化的行
UPDATE tgt
SET tgt.A = src.A
FROM tgt
JOIN src
ON tgt.B = src.B
WHERE tgt.A <> src.A;

• 所有关联操作前，必须给两表的关联键B创建统计信息，否则优化器会生成错误执行计划：

CREATE STATISTICS stats_tgt_B ON tgt(B);
CREATE STATISTICS stats_src_B ON src(B);

• 执行存储过程时将账号切换到更大的资源类（如XLarge RC），给计算节点分配足够内存，避免中间数据溢出到磁盘拖慢速度。
• 如果tgt是分区表，必须保证临时表、CTAS结果表的分区规则和tgt完全对齐，进一步减少全表扫描开销。

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