Apache Phoenix多JOIN查询执行计划疑问：行键关联为何全表扫描？

首先可以明确：Phoenix 4.13.1的执行计划显示FULL SCAN的话，实际执行时基本都会触发全表扫描——这个执行计划的可信度还是很高的，尤其是针对JOIN场景下的表扫描逻辑。你预期的RANGE SCAN没出现，大概率是因为Phoenix 4.x版本的优化器在处理多表JOIN时存在一些局限性，或者你的查询/表结构有一些细节没满足范围扫描的触发条件，下面具体分析：

为什么基于Rowkey的JOIN会触发全表扫描？ #

• JOIN顺序与驱动表的选择：如果你的查询中没有对驱动表（JOIN链条中第一个被扫描的表）设置任何rowkey范围过滤，Phoenix优化器可能会选择全扫驱动表，然后对后续JOIN的表做嵌套循环匹配。这种情况下，哪怕JOIN条件是基于rowkey，优化器也无法推导出后续表的rowkey范围，只能触发全表扫描来匹配所有可能的行。
• Rowkey匹配的完整性问题：如果你的表使用了复合Rowkey（比如多列拼接的主键），而JOIN条件只匹配了Rowkey的非前缀部分，Phoenix无法利用Rowkey的有序性做范围扫描。比如表的Rowkey是user_id || order_date，但JOIN条件只用到了order_date，这种非前缀匹配只能走全表扫描。
• 统计信息缺失：Phoenix 4.x的优化器严重依赖表的统计信息（比如行数量、Rowkey分布）。如果你的table_two和table_three从未执行过ANALYZE TABLE操作，优化器无法判断表的大小和数据分布，会默认选择保守的全表扫描策略，而不会尝试优化为范围扫描。
• JOIN类型的限制：如果你的查询使用了LEFT JOIN或FULL JOIN而非INNER JOIN，Phoenix为了确保右表的所有行都被纳入结果（哪怕驱动表没有匹配的行），会强制对右表做全表扫描，而不会使用范围扫描。

如何验证实际执行行为？ #

你可以通过开启Phoenix的DEBUG日志来确认扫描类型：

1. 调整Log4j配置，添加log4j.logger.org.apache.phoenix=DEBUG
2. 执行你的查询，查看日志中关于table_two和table_three的扫描语句：
   • 如果日志显示SCAN 'table_two'且没有STARTROW/STOPROW参数，那就是实打实的全表扫描；
   • 如果有明确的STARTROW和STOPROW，说明优化器最终还是触发了范围扫描（这种情况可能是执行计划显示的信息有延迟，或者你有未注意到的过滤条件）。

如何优化为RANGE SCAN？ #

• 收集表统计信息：执行ANALYZE TABLE table_two, table_three;，让优化器获取表的元数据，重新生成执行计划后大概率会选择更优的扫描策略。
• 添加驱动表的范围过滤：如果业务允许，给JOIN链条中的第一个表添加Rowkey范围条件，比如WHERE table_one.rowkey BETWEEN '20230101' AND '20231231'。优化器会把这个范围传递给后续JOIN的表，触发对应的RANGE SCAN。
• 调整JOIN顺序：把有明确Rowkey过滤条件的表放在JOIN的最前面，让优化器以它作为驱动表，这样后续表就能继承范围条件。
• 确保Rowkey匹配是前缀/完整匹配：如果使用复合Rowkey，JOIN条件要匹配Rowkey的前缀部分（或完整Rowkey），比如表的Rowkey是user_id || order_date，JOIN条件用table_one.user_id = table_two.user_id就能触发前缀范围扫描。

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