GreatSQL重磅特性，InnoDB并行并行查询优化测试

InnoDB并行查询优化怎么实现的？

根据B+树的特点，可以将B+树划分为若干子树，此时多个线程可以并行扫描同一张InnoDB表的不同部分。对执行计划进行多线程改造，每个子线程执行计划与MySQL原始执行计划一致，但每个子线程只需扫描表的部分数据，子线程扫描完成后再进行结果汇总。通过多线程改造，可以充分利用多核资源，提升查询性能。

优化后，在TPC-H测试中表现优异，最高可提升30倍，平均提升15倍。

该特性适用于周期性数据汇总报表之类的SAP、财务统计等业务，例如月初、月底跑批业务等。

使用限制：

• 暂不支持子查询，可想办法改造成JOIN。
• 暂时只支持ARM架构平台，X86架构平台优化也会尽快完成。

关于该Patch详情见：https://support.huaweicloud.com/fg-kunpengdbs/kunpengdbs_20_0005.html

本文针对 InnoDB引擎的并行查询优化 特性进行对比测试。

1、测试环境

服务器：神州鲲泰R222，华为Hi1616 * 2（主频 2400 MHz 共64个逻辑CPU），256G内存。

操作系统：Docker 20.10.2，Docker容器下的CentOS Linux release 7.9.2009，Linux 4.15.0-29-generic。

本次测试采用TPC-H，dbgen构造测试数据参数 dbgen -vf -s 50，导入后数据库物理大小约70G。GreatSQL关键配置：

#运行Q10测试时，需要较大临时表 temptable_max_ram = 6G #使得本测试基于纯内存场景 innodb_buffer_pool_size=96G #InnoDB并行查询优化 #global级别，设置并行查询的开关，bool值，on/off。默认off，关闭并行查询特性。可在线动态修改。 force_parallel_execute = ON #global级别，设置系统中总的并行查询线程数。有效值的范围是（0, ULONG_MAX），默认值是64。 parallel_max_threads = 64 #global级别，并行执行时leader线程和worker线程使用的总内存大小上限。有效值的范围是（0, ULONG_MAX），默认值是1G parallel_memory_limit = 32G