Azure Synapse Analytics多表内连接count查询超时排查

这个超时和数据量本身无关——毕竟单表查询、4表关联、TABLE_2和TABLE_5两表关联都能正常跑，且已经确认TABLE_2和TABLE_5关联不会产生数据膨胀，核心问题是Azure Synapse专用SQL池的查询优化器在处理5表关联时生成了错误的执行计划，常见触发场景包括：

• 关联顺序选择错误：优化器没有按照逻辑先关联前4张表再关联TABLE_5，反而调整了关联顺序，提前对大表做了不必要的跨节点数据移动（Shuffle），甚至产生了远超预期的中间结果集，哪怕最终关联结果无膨胀，中间阶段的数据倾斜、数据量暴涨就会直接拖到查询超时。
• 统计信息偏差：优化器依赖列级统计信息估算各步骤的返回行数，加入第5张表后，多表关联的行数估算误差陡增，最终选错了关联算子（比如给大表关联选了适合小表的Nested Loop）、选错了数据分布移动策略（比如该广播小表的时候做了全量shuffle）。
• 内存不足触发溢写：5表关联的中间结果需要的内存比4表关联更高，如果当前查询分配的资源类内存不够，中间计算结果会被写到磁盘临时存储，读写性能陡降导致超时。

按优先级从高到低尝试：

• 拆分查询绕开优化器的错误选择
  不要一次性写5表关联，先把前4张表关联后需要用到的关联键存为按KEY哈希分布的临时表，再和TABLE_5做关联，从根源上避免优化器乱选关联顺序：

  -- 先落前4表关联的去重KEY，按KEY做哈希分布避免后续关联跨节点挪数据
  CREATE TABLE #TMP_PRE_JOIN
  WITH (
      DISTRIBUTION = HASH(KEY),
      HEAP
  )
  AS
  SELECT DISTINCT t2.KEY
  FROM TABLE_1 t1
  INNER JOIN TABLE_2 t2 ON t1.KEY = t2.KEY
  INNER JOIN TABLE_3 t3 ON t2.KEY = t3.KEY
  INNER JOIN TABLE_4 t4 ON t3.KEY = t4.KEY;
  
  -- 关联第5张表计算最终count
  SELECT COUNT(*)
  FROM #TMP_PRE_JOIN tmp
  INNER JOIN TABLE_5 t5 ON tmp.KEY = t5.KEY;
  

• 更新关联键的全量统计信息
  对所有表的关联KEY列做全量统计信息更新，修正优化器的行数估算偏差：

  UPDATE STATISTICS TABLE_1 (KEY) WITH FULLSCAN;
  UPDATE STATISTICS TABLE_2 (KEY) WITH FULLSCAN;
  UPDATE STATISTICS TABLE_3 (KEY) WITH FULLSCAN;
  UPDATE STATISTICS TABLE_4 (KEY) WITH FULLSCAN;
  UPDATE STATISTICS TABLE_5 (KEY) WITH FULLSCAN;
  

• 加查询提示强制执行计划
  如果不想拆分SQL，可以直接加提示强制优化器按你写的顺序做哈希关联，避免乱选执行计划：

  SELECT COUNT(*) 
  FROM TABLE_1
  INNER HASH JOIN TABLE_2 ON TABLE_1.KEY = TABLE_2.KEY
  INNER HASH JOIN TABLE_3 ON TABLE_2.KEY = TABLE_3.KEY
  INNER HASH JOIN TABLE_4 ON TABLE_3.KEY = TABLE_4.KEY
  INNER HASH JOIN TABLE_5 ON TABLE_2.KEY = TABLE_5.KEY
  OPTION (FORCE ORDER);
  

  其中FORCE ORDER会严格按照SQL书写顺序执行关联，HASH JOIN强制使用适合大表关联的哈希连接算子，避免选低效的嵌套循环连接。
• 调整查询分配的资源
  如果以上操作后仍然缓慢，检查当前查询绑定的资源类，小资源类分配的内存较低，容易触发中间结果溢写磁盘，可以切换到更高等级的资源类（比如从smallrc切换到largerc），给查询分配更多计算内存。

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