Azure Databricks SQL查询长期无响应（超15小时）排查求助

1. 分析查询执行计划差异 #

• 对第8组及之后的查询执行 EXPLAIN EXTENDED，对比前7组正常查询的执行计划：
  • 重点检查是否出现笛卡尔积（关联条件缺失或错误），这会让小数据集产生海量计算，直接拉满CPU
  • 确认是否存在无索引的全表扫描，即使数据量小，过滤条件不匹配索引类型（比如字符串字段用数值比较）也会导致低效扫描
• 查看执行计划中的shuffle阶段，是否有数据倾斜迹象（某几个任务处理的数据量远超平均）

2. 排查集群运行状态 #

• 打开Spark UI的Executors页面：
  • 检查是否有executor频繁重启、崩溃，导致任务反复重试
  • 查看CPU、内存的实时使用率，确认是否是某几个executor占用了全部CPU资源
• 查看SQL页面的查询详情：
  • 追踪每个阶段的任务进度，是否有任务一直处于running状态但无数据输出
  • 检查GC指标，即使内存剩余，频繁Full GC也会导致CPU占用异常偏高

3. 校验临时视图/表的有效性 #

• 重新检查第8组查询所用临时视图的定义：
  • 对比前7组的视图逻辑，是否存在隐性类型转换（比如日期字段用字符串过滤）、过滤条件遗漏
  • 确认视图数据源的统计信息是否过期，执行ANALYZE TABLE <表名> COMPUTE STATISTICS更新统计信息，让Spark生成更优的执行计划
• 放弃复用中间视图，直接从原始表重新提取过滤数据，排除视图元数据损坏的可能

4. 重置会话与清理残留资源 #

• 重启当前笔记本的Spark会话（无需重启集群），清除会话中残留的广播变量、累加器或未释放的临时资源
• 检查是否有自定义UDF或全局变量在后续查询中被修改，导致逻辑异常（比如UDF出现死循环、低效计算）

5. 排查查询逻辑的细微差异 #

• 逐行对比第8组与前7组的查询语句：
  • 检查过滤条件的运算符（= vs LIKE）、分组字段、聚合函数嵌套层级的差异，这些细微变化可能导致执行计划剧变
  • 确认是否存在递归逻辑、过度嵌套的窗口函数，这类逻辑在小数据集上也可能触发大量计算

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