为何QuestDB双字段分区查询远慢于单字段？如何优化？

可能的慢查询原因 #

• 索引不匹配：core_price表应该存在(sym, ts DESC)的复合索引，执行latest on ts PARTITION by sym时，数据库可以直接通过索引快速定位每个sym分组的最新时间戳记录，无需全表扫描。而fx_price表缺少(ccy1, ccy2, ts DESC)这类复合索引，导致数据库需要全表扫描后对每个(ccy1, ccy2)分组做排序聚合，耗时剧增。
• 分区策略差异：两张表看似结构规模一致，但分区方式可能不同。如果core_price是按sym做分区，查询时只需扫描对应分区；而fx_price未按(ccy1, ccy2)做分区，或分区键不合理，导致查询需跨大量分区，IO开销大幅上升。
• 数据分布差异：部分(ccy1, ccy2)分组的历史数据量远大于core_price的sym分组，即使总数据量相当，分组计算最新值时的排序、聚合开销也会显著增加。

优化方法 #

• 创建针对性复合索引：给fx_price表创建(ccy1, ccy2, ts DESC)的复合索引。该索引能让数据库直接定位每个(ccy1, ccy2)分组的最新ts记录，彻底避免全表扫描和分组排序操作。
• 调整分区策略：若fx_price是分区表，将分区键设置为(ccy1, ccy2)（如哈希分区），减少查询时需要扫描的分区数量，降低IO开销。
• 更新统计信息：确保数据库统计信息为最新状态，避免优化器选择低效执行计划。例如：
  • PostgreSQL：执行ANALYZE fx_price;
  • MySQL：执行ANALYZE TABLE fx_price;
• 预计算最新值：如果业务允许，通过物化视图或定时任务，将每个(ccy1, ccy2)的最新rate预先存储到一张小表中，查询时直接读取该表，完全规避实时分组计算的开销。

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