Trino 查 Hive 表很慢，你怎么排查？
自测：先别看答案
试着用 1～2 分钟把这道题讲出来（说出声或写下要点），再展开对照。
面试怎么回答
我先用 EXPLAIN ANALYZE 或 Web UI 定位慢在哪个 Stage，是扫描、JOIN 还是在排队。扫描慢就检查分区裁剪是否因为函数或隐式转换失效、分区里是否小文件过多、是不是列式格式；JOIN 慢就看是否因为缺少统计信息把大表错误广播，用 ANALYZE 补统计信息，确认动态过滤生效；最后看资源组排队和任务倾斜。整个过程是先定位、再对症，而不是直接加资源。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
用 Trino 查一张 Hive 表，平时几秒，今天跑了几分钟。面试官想听的不是「加机器」，而是排查顺序。
第一步：看执行计划和查询统计
先用 EXPLAIN ANALYZE 或 Web UI 看每个 Stage 的耗时、输入行数和数据量，找出时间花在哪：是扫描、JOIN、聚合，还是排队等资源。
第二步：扫描是不是太多
- 分区裁剪有没有生效：过滤条件要直接作用在分区列上；对分区列套函数、或者类型不一致导致隐式转换，都会让裁剪失效，变成全表扫描。
- 小文件太多：一个分区里成千上万个小文件，会让 split 数暴增，调度和打开文件的开销远大于真正读数据的时间。治理办法是在写入侧合并小文件。
- 列式格式和谓词下推：Parquet、ORC 才能只读需要的列、利用文件统计信息跳过数据；文本格式只能整行读取。
第三步：JOIN 策略对不对
- 小表应该广播（broadcast），大表之间用分区 JOIN（partitioned）。表没有统计信息时，优化器可能把大表当成小表广播，导致单节点内存打满。用
ANALYZE收集统计信息，或者调整join_distribution_type。 - 动态过滤（dynamic filtering）：维表过滤后的 key 集合可以下推到事实表的扫描阶段，大幅减少读取量。确认它在查询里生效了。
第四步：资源和数据倾斜
- 查询在排队，说明是资源组的并发上限或内存配额不够，不是查询本身慢。
- 某个 Task 的处理行数远多于其他，说明有数据倾斜，要从 JOIN key 或分组 key 的分布入手。
这道题在刷题路线里：湖仓与 OLAP