ByConity项目优化器对分区键子查询过滤的性能优化分析

背景介绍

在分布式数据库系统ByConity中，当查询条件中的分区键过滤条件来自于子查询时，查询性能可能会显著下降。本文通过一个典型场景分析这一问题，并探讨优化方案。

问题现象

我们创建一个测试表test1，按日期字段pt_d进行分区，并插入大量测试数据。当执行以下两种查询时，性能差异明显：

1. 分区键直接指定具体值（0.02秒完成）

select name from (
   select name, sum(1) as id_users, sum(key) as all_id_users 
   from db.test1
   where pt_d = '2020-04-09'
   group by name
   order by id_users desc
) t where t.all_id_users>300

2. 分区键通过子查询获取（0.3秒完成）

select name from (
   select name, sum(1) as id_users, sum(key) as all_id_users 
   from db.test1
   where pt_d = (select max(pt_d) from db.test1)
   group by name
   order by id_users desc
) t where t.all_id_users>300

性能差异原因分析

当启用优化器(enable_optimizer=1)时，第二种查询会使用Join操作来处理子查询条件，而不是先执行子查询获取分区键值再进行分区裁剪。这种执行计划导致需要扫描更多数据，性能较差。

相比之下，禁用优化器(enable_optimizer=0)时，查询耗时降至0.08秒，因为传统执行引擎会先执行子查询获取具体分区键值。

优化方案

ByConity提供了两种参数来优化这类场景：

1. early_execute_scalar_subquery：强制先执行标量子查询
2. early_execute_in_subquery：强制先执行IN子查询

设置early_execute_scalar_subquery=true后，优化器会先执行select max(pt_d) from db.test1获取具体分区键值，然后进行分区裁剪，显著提升性能。

实现原理

这种优化属于"子查询提前执行"技术，核心思想是：

1. 识别出可以独立执行的子查询
2. 在执行主查询前先执行这些子查询
3. 将子查询结果作为常量用于主查询优化
4. 特别是对于分区键条件，可以提前确定需要扫描的分区范围

最佳实践建议

对于包含分区键子查询过滤的SQL，建议：

1. 优先使用early_execute_scalar_subquery参数
2. 对于复杂子查询，考虑重写为JOIN或临时表
3. 定期收集表统计信息(create stats)以帮助优化器决策
4. 监控查询计划，确保分区裁剪有效

总结

ByConity优化器在处理分区键子查询过滤时，默认行为可能导致性能问题。通过合理使用子查询提前执行参数，可以显著提升这类查询的性能。理解优化器的工作原理和可用参数，有助于开发人员编写更高效的SQL查询。