1 法律声明

阿里云提醒您在阅读或使用本文档之前仔细阅读、充分理解本法律声明各条款的内容。如果您 阅读或使用本文档，您的阅读或使用行为将被视为对本声明全部内容的认可。

1. 您应当通过阿里云网站或阿里云提供的其他授权通道下载、获取本文档，且仅能用于自身的 合法合规的业务活动。本文档的内容视为阿里云的保密信息，您应当严格遵守保密义务; 未经 阿里云事先书面同意，您不得向任何第三方披露本手册内容或提供给任何第三方使用。
2. 未经阿里云事先书面许可，任何单位、公司或个人不得擅自摘抄、翻译、复制本文档内容的 部分或全部，不得以任何方式或途径进行传播和宣传。
3. 由于产品版本升级、调整或其他原因，本文档内容有可能变更。阿里云保留在没有任何通知 或者提示下对本文档的内容进行修改的权利，并在阿里云授权通道中不时发布更新后的用户 文档。您应当实时关注用户文档的版本变更并通过阿里云授权渠道下载、获取最新版的用户 文档。
4. 本文档仅作为用户使用阿里云产品及服务的参考性指引，阿里云以产品及服务的“现状”、“有 缺陷”和“当前功能”的状态提供本文档。阿里云在现有技术的基础上尽最大努力提供相应的 介绍及操作指引，但阿里云在此明确声明对本文档内容的准确性、完整性、适用性、可靠性 等不作任何明示或暗示的保证。任何单位、公司或个人因为下载、使用或信赖本文档而发生 任何差错或经济损失的，阿里云不承担任何法律责任。在任何情况下，阿里云均不对任何间 接性、后果性、惩戒性、偶然性、特殊性或刑罚性的损害，包括用户使用或信赖本文档而遭 受的利润损失，承担责任 (即使阿里云已被告知该等损失的可能性)。
5. 阿里云网站上所有内容，包括但不限于著作、产品、图片、档案、资讯、资料、网站架构、网 站画面的安排、网页设计，均由阿里云和/或其关联公司依法拥有其知识产权，包括但不限于 商标权、专利权、著作权、商业秘密等。非经阿里云和/或其关联公司书面同意，任何人不得 擅自使用、修改、复制、公开传播、改变、散布、发行或公开发表阿里云网站、产品程序或内 容。此外，未经阿里云事先书面同意，任何人不得为了任何营销、广告、促销或其他目的使用、 公布或复制阿里云的名称 (包括但不限于单独为或以组合形式包含“阿里云”、“Aliyun”、“万网” 等阿里云和/或其关联公司品牌，上述品牌的附属标志及图案或任何类似公司名称、商号、商 标、产品或服务名称、域名、图案标示、标志、标识或通过特定描述使第三方能够识别阿里 云和/或其关联公司)。
6. 如若发现本文档存在任何错误，请与阿里云取得直接联系。

2 摘要

PolarDB 弹性并行查询（Elastic Parallel Query，简称ePQ）是自PolarDB MySQL诞生伊始就致力于研发的企业级查询加速功能，当您的查询代价或查询数据量达到一定阈值，就会自动启动并行执行引擎，从而使查询耗时大幅降低，满足您对复杂分析查询低时延的需求。

并行查询的基本原理是将一个大的复杂查询拆解为多个子任务，派发到多个worker线程中进行并发计算，最终再将结果汇总并返回给客户端，从而实现并行加速。在PolarDB MySQL 8.0.2版本中ePQ具备了多节点分布式并行计算能力，可以根据集群实时负载情况做自适应弹性跨机调度，不仅能够提升集群资源利用率，还能突破单机计算瓶颈，获得更好的线性查询加速能力，进一步降低查询耗时。此外并行查询还提供了严格的资源限制能力，防止并行计算占用过多资源影响其它普通查询业务。

图1 - PolarDB 弹性并行查询

PolarDB ePQ适用于绝大对数SELECT语句，分析查询语句中几乎所有算子都可以进行并行优化，包括大表扫描、多表JOIN、聚集、分组、排序、窗口函数、子查询等。

PolarDB ePQ功能配置非常简单，开箱即用，开启后客户应用程序无需任何变更即可生效，且无额外购买成本，有效利用集群内空闲计算资源进行查询加速。如果您业务中有较多慢查询，并且集群整体负载不是持续处于高水位，则非常建议开启ePQ来实现透明的查询加速；或者您已经是PolarDB MySQL 8.0.1版本的客户且已开启了并行查询，强烈建议您升级到8.0.2版本，弹性多机并行可以为您提供更好的加速体验。

3 目标读者

本文假定目标读者具有 PolarDB/MySQL DBA 或者 MySQL 数据库相关应用开发者的实践经验。

4 引言

PolarDB-MySQL是阿里巴巴自研的新一代云原生关系数据库，在存储计算分离架构下，利用了软硬件结合的优势，为用户提供具备极致弹性、高性能、海量存储、安全可靠的数据库服务，非常适用于高并发的短事务型查询场景。但由于原生MySQL是单线程执行模型，对分析型的复杂查询的处理能力一直较弱，尤其是当前日益可弹性扩展的分布式存储，用户表数据越来越大，分析型查询越来越慢，即便扩容计算节点也无法加快查询速度，直到业务侧无法容忍，一般采用如下两种方式来解决：

1. 拆分库表，需要改造业务侧代码，开发和运维改造成本较高；
2. 引入分析型数据库，优势是分析足够快，缺点是需要将数据同步一份至分析库，查询无法保证实时性，独立的数仓系统需要额外的存储和计算节点及运维管理，成本投入高。

对云原生关系数据库的用户而言，简单易用以及成本控制往往是首先要考虑的，希望在一套系统内满足OLTP（事务型查询）的基础上，也能够满足一定场景的OLAP（分析型查询），比如一些报表查询、即席分析查询的低时延需求，尤其是面对业务数据的日益增长，数据库能够提供稳定可预期的查询性能。

经过长期的统计观察，线上云原生关系数据库的整体资源利用率都偏低，有大量计算资源处于闲置状态。对于用户来说，一方面是分析类查询的高时延，一方面是集群计算资源存在浪费，在当今强调降本增效的大环境下，急需一种技术能利用空闲的计算资源对大查询进行加速。并行查询技术，能够有效利用多核CPU进行查询加速，是关系型数据库提升查询性能非常有效的手段，像Oracle、SQL Server、DB2等传统数据库也都有非常成熟的并行查询解决方案。

图2 - 弹性并行查询

PolarDB 弹性并行查询（Elastic Parallel Query，简称ePQ）是PolarDB MySQL发布的企业级查询加速功能，同时支持单机并行和多机并行两种模式，单机并行是仅利用单个节点内的计算资源并行加速查询，多机并行是利用集群内任意节点的空闲资源进行并行加速，具备分布式执行能力，不仅能够突破单机计算瓶颈，还能有效提升整个集群的资源使用率。

本文介绍PolarDB ePQ的基本架构，功能及性能优势以及背后的技术原理，同时还会介绍PolarDB ePQ的功能使用方法（请访问我们官方网站以获得最新指引）。该文档也会介绍ePQ适用的典型加速场景以及一些使用ePQ对业务进行加速的客户案例。

PolarDB MySQL 8.0版本均支持并行查询，但8.0.1版本中仅支持单机并行，8.0.2版本为新一代架构支持弹性多机并行，本文中介绍的架构、功能及性能优势均是基于8.0.2版本。

5 PolarDB ePQ 整体架构

PolarDB ePQ的目标是打通集群计算层的计算资源，基本原理是将一个复杂查询任务拆分为多个子任务，子任务可以被派发到同集群内的任意节点执行计算，有效利用集群内其它节点空闲计算资源（CPU、 内存等）来加速查询。PolarDB ePQ功能属于内核特性，任意节点都可以提供完整的服务，如下图是从内核视角看到的弹性并行查询的架构图：

图-3 PolarDB ePQ架构图

• 并行优化器（PQ Optimizer） ，在串行计划的基础上做信息提取，然后基于代价的枚举拆分出最优的子计划切片（Plan Slices）。
• 全局资源视图（Global Resource View），维护集群内所有节点的实时负载信息，方便协调器快速找出有空闲计算资源的节点。
• 任务协调器（Coordinator），根据实时资源负载情况，从任务队列中调度执行。
• 弹性并行执行器（Parallel Execution Engine），负责将被调度的子计划切片（Plan slices）生成对应的Physical Plan，然后交给Executor模块执行。如果是远程节点执行，还需要将Phsical Plan序列化，通过内部网络通道传输到远程节点上执行。
• 资源管理器（Resource Manger），提供限制并行查询使用资源上限的能力，比如当CPU使用率超过了70%就不再选择并行执行。
• 基于共享存储的跨机并行架构，可以保证查询结果的实时性，并在跨节点一致性视图机制的保证下，子任务在任意节点执行都能读取到正确的数据。

从用户视角看，PolarDB ePQ以集群地址（Endpoint）的方式对外提供服务，不同节点分组构成集群分组，不同场景的业务可选择配置不同的分组，各自配置合适的并行策略，以实现业务隔离。如下图示ePQ的部署架构图：

图-4 PolarDB ePQ 部署架构

6 PolarDB ePQ 产品特性

本章讲述PolarDB ePQ的功能和性能特点，您可以根据您的业务需求重点查看相关方面的介绍。PolarDB ePQ 计算引擎主要针对业务中的复杂分析查询进行并行加速，如果您的业务中不仅要满足高并发的事务型查询，还有一定场景的分析类查询，要求较高的实时性，您可以开启ePQ特性体验PolarDB提供的一体式HTAP解决方案。

以下测试如无特别说明，均为在阿里云线上购买的 PolarDB MySQL 中实施，实例规格为mmx8.4xlarge， 该规格具有 32 核 CPU 以及 256G 内存，底层的分布式存储可以提供100TB级的容量，具体的配置 可以参考阿里云官网。 

6.1 开箱即用

如果您已经是PolarDB-MySQL的客户，业务侧总是反馈某些查询特别慢，或是在SQL洞察中看到有慢查询需要治理，而且实例资源利用率并不持续维持在高水位，那开启PolarDB ePQ功能是您非常好的选择。在集群地址的配置页面，点击开启并行查询并配置并行度，应用程序无需做任何变更即可享受并行查询带来的查询加速功能。

图-5 开启并行查询配置页面

并行查询的并行度一般建议初始设置为CPU核数的1/4，观察集群资源负载一段时间（比如7天），若集群仍有较多空闲资源，可适当逐步提升并行度。

开启ePQ后，PolarDB 优化器会根据查询的代价或是查询的数据量多少，自动选择是否进行并行加速，而且也会自动考虑当前集群的实时负载情况，客户只需最少量的配置，就能体验一体式的查询加速能力。当然如果客户想精细化的控制，我们也提供了精细的参数控制，比如参数records_threshold_for_parallelism和cost_threshold_for_parallelism可以调整是否并行的阈值，具体使用细节请您参见最新的官方使用文档。

6.2 极致性能提升

为了验证PolarDB ePQ在分析类查询场景的加速效果，我们使用了TPC-H benchmark。TPC-H是业界常用的一套基准，由TPC委员会制定发布，用于评测数据库的分析型查询能力。TPC-H查询包含8张数据表、22条复杂的SQL查询，大多数查询包含若干表Join、子查询和Group by聚合等。

图-6 PolarDB ePQ加速效果对比

通过以上测试结果图得出，TPC-H中22条SQL均可以被加速，并行查询单节点平均加速比在17倍，最高加速比56倍；跨4节点并行，平均加速比在59倍，最高加速比159倍；通过对比发现ePQ有良好的线性加速能力（随节点个数增加，加速效果成线性提升），可以通过升级实例规格或是增加节点个数，获得更好的性能提升。

如上tpch测试数据，仅对库表添加了主外键约束，未建立任何其它二级索引，具体测试方法请参见 PolarDB 性能白皮书。

6.3 自适应弹性调度

自动弹性扩缩容以及Serverless是云原生数据库PolarDB的核心能力，根据集群资源随客户业务负载动态弹降。原生MySQL是单线程执行模式，无法通过Scale Up或Scale Out对分析型复杂查询进行加速，因为一个查询只能运行在一个线程，最多只能利用1个CPU来进行计算。

PolarDB ePQ支持自适应弹性调度，根据集群实时负载情况，来动态调整查询执行的并行度和选择在哪几个节点上运行。当集群发生Scale Up或Scale Out时，ePQ采集到当前集群中有更多的计算资源，会自动上调并行度，或是将排队中的查询调度到新扩容出的计算节点上，从而使分析类查询获得更低的时延。

图-7 PolarDB ePQ 横向扩容调度示意图

如上图所示，PolarDB ePQ的自适应弹性调度不仅可以对查询进行更好的加速，还可以起到负载均衡的效果，避免某些节点负载过高影响正常业务。

6.4 MySQL协议100%兼容

PolarDB并行查询的执行引擎是嵌入在PolarDB MySQL计算引擎的内核扩展特性，与原有系统共享同一套SQL解析和优化器，保证了SQL语法、类型、行为的100%完全兼容。

6.5 稳定可靠

PolarDB 并行查询是自PolarDB MySQL诞生伊始就致力于研发的企业级查询加速功能，从2019年发布第一个版本至今，经过多年的迭代演进，在云上已稳定服务上千个客户，无论是性能还是稳定性都达到了企业级功能的标准。

7 PolarDB ePQ 典型加速场景

PolarDB ePQ适用于绝大多数SELECT语句，查询语句中几乎所有算子都可以并行加速，包括大表扫描、多表JOIN、聚合、分组、排序、窗口函数、子查询等。无论多复杂的查询语句，通常都是由上述这些基本算子组合而成，本章通过示例讲解一些典型场景的加速原理和性能提升情况，以便您基于此测试场景和SQL组合模式估算真实业务在PolarDB ePQ中的性能表现。

本章节下述测试如无特别说明，均为在阿里云线上购买的 PolarDB MySQL 中实施，实例规格为mmx8.4xlarge， 该规格具有 32 核 CPU 以及 256G 内存，具体的配置可以参考阿里云官网。 测试数据均采用TPC-H SF100，其中相关表的数据量级为：

lineitem ： 600037902 rows

orders : 150000000 rows

customer : 15000000 rows

7.1 分组聚合计算

分组聚合（Aggregation）是分析类查询的基础操作，将数据按照分组列分组并计算聚合结果，常见的聚合函数有SUM/COUNT/AVG/MIN/MAX等。比如TPCH中Q1查询，在lineitem订单表上查询某个时间段内，对已经付款的、已经运送的等各类商品进行统计，包括业务量的计费、发货、折扣、税、平均价格等信息。

# TPCH - Q1
select
        l_returnflag,
        l_linestatus,
        sum(l_quantity) as sum_qty,
        sum(l_extendedprice) as sum_base_price,
        sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
        sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
        avg(l_quantity) as avg_qty,
        avg(l_extendedprice) as avg_price,
        avg(l_discount) as avg_disc,
        count(*) as count_order
from
        lineitem
where
        l_shipdate <= date '1998-12-01' - interval '81' day
group by
        l_returnflag,
        l_linestatus
order by
        l_returnflag,
        l_linestatus
limit 1;

并行分组聚合的原理是多个worker线程各自扫描表的一部分数据，每个worker线程各自进行局部聚合计算，然后由Leader线程汇总结果并返回给客户端。最耗时的表扫描和分组聚合计算，被分摊到多个worker线程并发执行，极大提高了查询效率，执行流程如下图所示：

图-8 分组聚合并行执行流程

测试结果如下表所示，未开启ePQ时查询性能和节点个数无关，当开启ePQ后，单节点并行提升27倍，2节点提升56倍，4个节点提升100倍，随节点个数的增加还能获得接近线性的提升。

7.2 多表连接（Join）

Join操作是关系型数据库查询中常用的基础操作，在用户使用关系型数据库时，一般都会遵循数据库范式进行库表Schema设计，在查询时使用多表连接来进行查询，分析类查询会有更复杂的多表Join的操作，那么多表连接的性能显得格外重要了。

我们以TPC-H Q3语句为例，查询得到收入在前10位的尚未运送的订单。在指定的日期之前还没有运送的订单中具有最大收入的订单的运送优先级（订单按照收入的降序排序）和潜在的收入。

# TPCH - Q3
select
        l_orderkey,
        sum(l_extendedprice * (1 - l_discount)) as revenue,
        o_orderdate,
        o_shippriority
from
        customer,
        orders,
        lineitem
where
        c_mktsegment = 'HOUSEHOLD'
        and c_custkey = o_custkey
        and l_orderkey = o_orderkey
        and o_orderdate < date '1995-03-03'
        and l_shipdate > date '1995-03-03'
group by
        l_orderkey,
        o_orderdate,
        o_shippriority
order by
        revenue desc,
        o_orderdate limit 10;

PolarDB ePQ支持将Join算子下推到worker线程中并行执行，并行执行流程和前述分区聚合原理一致，就不再赘述。经过测试发现，开启ePQ后，单个节点并行提升了18.9倍，2个节点提升32倍，4个节点提升63.5倍，具体测试结果如下表格所示：

7.3 排序分页（OrderBy+Limit）

排序分页（OrderBy+Limit）一般作为一个查询语句最后执行的算子，对最终结果进行排序，然后选取分页偏移的数据，待排序的数据可能是扫表、多表JOIN、聚合等算子的结果。为说明PolarDB ePQ针对排序算子的加速原理与效果，我们通过如下一条简单SQL进行示例说明：

select * from lineitem
where
	l_shipdate <= date '1998-12-01' - interval '81' day
order by
	l_returnflag,
	l_linestatus
limit 1000, 10;

并行排序的原理是由多个worker线程各自对部分数据进行局部排序，再由leader线程汇总结果并做归并排序，最后将最终排好序的结果返回给客户端。并行排序的执行流程如下图所示：

图-9 并行排序的执行流程

测试结果如下表所示，未开启ePQ时查询性能和节点个数无关，当开启ePQ后，单节点有22倍的提升，随节点个数的增加还能获得接近线性的提升。

7.4 关联子查询

在分析类查询中，相关子查询一般是比较耗时的操作，因为关联子查询本身计算量就比较复杂，还要被执行多次，非常容易成为一个查询的瓶颈点。比如如下SQL语句，子查询用来计算符合条件的商品订单的平均质量，会被反复执行：

SELECT o_orderpriority, count(*) AS order_count
FROM orders
WHERE o_orderdate >= '1995-01-01'
	AND o_orderdate < date_add('1995-01-01', INTERVAL '3' MONTH)
	AND 20 < (
		SELECT avg(l_quantity)
		FROM lineitem
		WHERE l_orderkey = o_orderkey
			AND l_commitdate < l_receiptdate
	)
GROUP BY o_orderpriority
ORDER BY o_orderpriority;

PolarDB ePQ中支持将关联子查询连同多表Join、聚合计算等算子一起下推到worker线程中并行执行，具体加速效果如下表格所示：

7.5 窗口函数

窗口函数是社区版MySQL 8.0 为提升查询分析能力而引入的功能，也被称为OLAP函数。比如TPC-H中的Q17语句，用来查询比平均供货量的百分之二十还低的小批量订单，其中子查询部分用来计算每个部门的平均供货量，子查询需要被反复执行导致性能瓶颈。为避免使用相关子查询，可以使用窗口函数来完成同样的查询操作，示例如下：

SELECT l_partkey, quantity
FROM (
	SELECT l_partkey
		, CASE 
			WHEN L_QUANTITY < 0.2 * avg(L_QUANTITY) OVER (PARTITION BY l_partkey) THEN L_QUANTITY
			ELSE NULL
		END AS quantity
	FROM lineitem
	WHERE l_partkey < 100000
) v
WHERE v.quantity IS NOT NULL
ORDER BY v.quantity
LIMIT 10;

PolarDB ePQ对窗口函数也做了全面支持，支持将窗口函数下推到worker线程中并行加速。测试数据如下表所示：

8 PolarDB ePQ 客户案例

8.1 小微企业财务云-用友畅捷通

8.1.1 客户简介

畅捷通是用友成员企业，公司成立于2010年3月，致力于成为“全球领先的小微企业云服务提供商”，提供以数智财税、数智商业为核心的小微企业云服务。

基于小微企业数智化的需求，畅捷通推出了一系列SaaS产品，包括好会计（票财税一体化数智财税SaaS产品）、好生意（面向微型商贸及零售企业的数智商业SaaS产品）、T+Cloud（「人、财、货、客」一体化SaaS产品）、好业财（面向商贸、零售、服务业小型企业的SaaS产品）、易代账（面向代账行业的数智财税SaaS产品）等，已为超过600万家小微企业提供数智财税及数智商业服务。

图-10：畅捷通官网

8.1.2 客户痛点

畅捷通的核心业务系统已经广泛使用PolarDB-MySQL产品，PolarDB-MySQL作为阿里巴巴自研的新一代云原生关系数据库，在存储计算分离的架构下，利用了软硬件结合的优势，为用户提供了具备极致弹性、高性能、海量存储、安全可靠的数据库服务，非常适用高并发的短事务型查询场景，良好的支撑了畅捷通的核心业务。

为了让企业经营者随时随地掌控经营，畅捷通的各个产品都会提供智能的商品和客户分析，实时的监控企业异常数据，辅助企业经营者做决策。比如客户、商品、业务员等可视化的销售分析，企业经营日报、预估利润实时查看，客户超期应收预警，出入库流水、收发存报表分析等。

这类业务的分析查询，对实时性和时延都有一定的要求，使用T+1离线OLAP系统架构已经不能满足需求，比较依赖PolarDB-MySQL能提供一定的复杂查询分析的能力。但原生MySQL是单线程执行模型，一个查询最多只能利用一个CPU来进行计算，随着日益弹性扩展的的业务数据，对降低复杂分析查询的时延的需求也越来越紧迫。

对于分析类的查询，从架构上可以引入分析库来做数据分析，但引入新系统要增加额外成本，客户当前对成本控制也非常重视。从性能监控分析，客户的实例整体资源使用率并不高，大部分时间都有很多空闲计算资源，客户希望在不引入新的成本投入，最好是有效利用当前集群的空闲计算资源来提升分析类查询的性能。

8.1.3 使用ePQ加速报表分析

PolarDB-MySQL推出了Elastic Parallel Query (ePQ)的特性，能够将一个大查询任务拆解为多个子任务，派发到多个线程上并发执行，并且支持了多机并行能力，并行加速能力可以随着集群内节点数量线性扩展，能够满足一定场景的分析查询需求。

开启ePQ对畅捷通业务的优势有：

• ePQ数据内核特性，开箱即用，对业务无侵入
• 线上稳定运行多年，完备诊断体系
• ePQ实现了全算子并行，高效的流水线支持，并支持弹性扩展为多机并行
• 底层统一共享存储，数据分析实时性高
• 0附加成本，有效利用当前集群空闲计算资源进行查询加速，提升资源利用率

客户在开启ePQ后，选取了5条业务中典型的分析类复杂查询，在不同业务压力场景下都进行了前后对比分析。集群规格为8c32G，共2个只读节点，开启ePQ并设置并行度为2，在低负载场景，有较多空闲资源，查询平均RT有3倍的提升；在中负载场景，集群负载在50%-85%抖动，平均RT有2倍的提升；在高负载场景，集群负载一直处在85%以上，触发了ePQ的资源限制机制，自动不再选择并行执行，避免继续并行带来负面影响。

图-11 畅捷通 ePQ OFF vs ePQ ON

如上业务数据对比发现，开启ePQ在空闲资源比较充足时，加速效果最理想，但在高负载压力下，也不会对业务造成负面影响。

8.2 人工智能 - 零犀科技

8.2.1 客户介绍

零犀科技成立于2018年，是一家致力于利用AI技术增强人工生产力的平台公司。

利用决策智能、因果识别，认知图谱等核心技术构建的办公室蓝领服务平台，打造行业最高生产力，改变行业成本结构。成立两年来，“零犀科技”已经在金融、保险等领域落地，实现人效 2倍的提升，实现业界最高生产力水平。

8.2.2 客户业务架构和痛点

零犀科技是一家探索暖心服务的认知智能公司，基于因果AI理论，深度理解现阶段技术实现情况，具有新意又脚踏实地地搭建出“兼具业务实践和技术创新”的新模型架构。

不仅打造了“需求探询”系统，还通过人机融合的方式率先以销售场景切入，不断在服务式销售过程中“理解和激发客户需求”，深入分析客户购买决策的复杂干扰因素，持续迭代模型效果，已为众多金融、保险、互联网等甲方客户提供直达关单的代理销售服务。基于因果AI的人机融合服务，零犀科技实现了有别于过去几年来市场比较常见的chatbot营销类SaaS产品，更专注于成交转化效果。 

图- 以因果AI为基底的服务场景

灵犀科技于2020年开始和阿里云合作，核心借助于阿里云的弹性计算、云原生serverless、云原生数据库、大数据平台和达摩院人工智能等服务完成业务的快速部署、弹性扩缩容、数据价值转换和降本提效。其中为解决海量运营数据的计算和分析，为实现实时运营数据精准营销，采用了云原生数据库PolarDB MySQL+实时数仓AnalyticDB MySQL的组合架构。PolarDB MySQL的计算存储分离架构，能够很好支撑海量在线业务数据的存储，再将数据同步汇聚到ADB中进行报表分析查询。

在当前的数据库架构中，一部分高实时性要求的分析查询需要直接在PolarDB中查询，因为客户使用的版本并不支持并行查询，大查询也只能单线程模式执行，查询时延非常高。将这些在线的查询转到ADB中查询，一是实时性不满足要求，二是即使牺牲一定的实时性，大量并发在线查询会对ADB造成较大的压力，从而导致其他服务不可用。客户希望PolarDB具体一定的分析查询加速的能力。

8.2.3 开启ePQ加速分析查询

在了解客户业务痛点后，经过观察客户实例整体负载并不高，建议客户升级到支持ePQ的8.0.2版本上来，开启ePQ后，不需要额外购买成本、运维成本，在PolarDB内部就能完成即席查询的加速。

以客户核心的催收业务实例为例，实例规格为16c64G，集群中共3个只读节点，升级后开启了ePQ，并设置初始并行度为4，经过一段时间的观察，对比未开启ePQ同期数据，客户实例慢查询数量减少到之前的1/8，慢查时延普遍提升了6~10倍，其中加速效果最好的一条查询从700秒被加速至50秒。

在开启ePQ后，慢查询加速效果显著，满足了实时分析类复杂查询的低时延需求，且利用空闲计算资源来进行查询加速，无需扩容增本也可以提效。并行度设置为4后，实例CPU负载上升到35%左右，集群还有较多空闲计算资源，还可以继续提升并行度获得更高加速效果。因为加速效果显著，客户已将剩余PolarDB实例全部升级到了8.0.2版本。

8.3 企业信息化-金万维

8.3.1 客户简介

北京金万维科技有限公司成立于2004年，是国内受信赖的企业信息化互联网平台。金万维定位于“携手各行业管理软件提供商为企业提供信息化服务”，通过提供“售前”、“售中”、“售后”的互联网平台服务，来帮助管理软件提供商及其用户成功。“售后”帮我吧是金万维旗下新一代全渠道智能客服平台，帮助企业快速连接客户、提升客服工作效率、提升客户满意度、降低服务成本等。

图-14：金万维-企业信息化

8.3.2 业务架构

帮我吧全国有25家分支机构，向全国十万家企业客户提供智能售后平台服务，并签约IT、家居、机械设备、共享服务、餐饮连锁、服务外包等行业100多家头部客户。服务的企业客户量大，部分行业的售售后流程复杂，导致帮我吧售后服务平台售后数据量大、售后业务逻辑复杂、客户对数据备份恢复时效性要求高、自定义查询器配置灵活带来大量复杂且查询慢的SQL、数据结构变更迭代快，这些都给数据库选型带来较大的挑战。

帮我吧技术团队做过较多不同尝试，比如MySQL、PXC、TiDB、MongoDB等，一直没有找到一个数据库引擎匹配帮我吧所有业务的方案，为满足业务需求，选择多写、数据复制等方式选用多个引擎来支撑不同业务。为降低维护成本、降低客户使用门槛，帮我吧在云上采用SaaS模式向企业客户提供售后智能服务平台，技术架构图如下：

图-15 金万维业务架构

8.3.3 客户痛点

为支持售后平台灵活配置和灵活查询，在配置界面和查询界面支持自定义查询器，可以选择不同的字段进行售后流程配置和查询配置，为规避频繁增加字段，技术侧在MySQL数据库将业务数据的多列转换为主键、配置列、列名key、列value值的方式，复杂售后流程的客户业务数据量放大较多少则十几倍多则几十倍，导致售后核心数据量大；在配置和查询功能上多个不同维度字段的组合，部分大客户的查询需要核心表自关联十几次甚至几十次，导致复杂业务大客户查询SQL复杂查询慢。

8.3.4 使用ePQ降本增效

帮我吧选择PolarDB前期切入点主要就是希望评估PolarDB的高并发读写能力能否支撑交互业务的同时，可以高性价比支持自定义查询器的大量数据、复杂多表关联查询性能。经过技术交流和功能、性能验证，PolarDB可以通过弹性多机并行(ePQ)，利用多个小规格节点(4核16GB)应对复杂查询。

弹性多机并行（Elastic Parallel Query）ePQ是PolarDB新推出通过多节点并行查询能力提速复杂查询的新特性。ePQ可以支持跨机并行查询（Parallel Query），利用多个节点的多线程并行查询、多线程CPU和IO资源提高查询语句速度，适用于大表查询、多表连接查询、计算量较大的查询等。通过突破单机CPU/IO瓶颈打通数据库集群计算层资源，提高百GB~10TB级别表复杂查询速度。

从帮我吧实际应用效果看，开启ePQ（并行度2）后与同期统计对比，慢查数量减少至原来的1/3，慢查时延普遍提升了3-6倍，ePQ给在这个场景下可以对复杂查询做较好的提速。借助多机并行能力用多个4核16GB节点支撑了之前需要16核32GB自建TiDB才能支持的业务。帮我吧技术负责人对该功能比较认可，反馈在业务运行中ePQ起了很大的作用，通过ePQ跨机并行提速和动态扩缩容能力降低了扩容的资源投入。

9 附录

9.1 PolarDB ePQ 官方文档链接

注意: 如因文档生成时间过于久远的原因, 导致部分链接失效或不可用, 请及时访问阿里云 PolarDB MySQL 的官方文档页面获取最新文档版本. 

表- PolarDB 官方链接