PolarDB-X 的 XPlan 索引选择

前言

对于数据库来说，正确的选择索引是基本的要求，选错索引轻则导致查询缓慢，重则导致数据库整体不可用。PolarDB-X存在多种不同的索引，局部索引、全局索引、列存索引、归档表索引。

局部索引就是单机数据库上常用的索引，目的是避免全表扫描。

全局索引是分布式数据库为了避免全分片扫描，冗余一份数据，采用与主表不同分区键的索引表。

列存索引是主表的列存副本，提供HTAP能力。

归档表索引是归档表上的列布隆过滤器，为归档表提供一定的TP查询能力。

本文主要介绍一种CN上的局部索引算法：XPlan索引选择。

什么是XPlan

PolarDB-X包含计算节点(CN)和数据节点(DN)，CN负责SQL解析、优化和执行，DN节负责数据的持久化，CN与DN之间通过RPC通信。DN 100%兼容Mysql，也是作为PolarDB-X标准版进行售卖的。

CN与DN之间RPC通信的内容其实就是标准的SQL，CN会将解析优化好的语法树转成SQL传给DN重新解析、优化。对比起来，将CN的语法树直接传给DN执行听起来就更优[1]。

但这样其实不一定好，主要原因是作为存算分离的架构，数据都在DN上，DN可以直接在数据上进行index dive，而CN的统计信息是采样出来的静态数据，更新不及时，所以基数估计比不上DN精确，导致索引选择准确度不如DN，在很多场景下节省的DN解析优化的消耗远不如选错索引的后果。

但对于用户核心的点查场景，这样的CN优化一遍DN再优化一遍的流程就会成为瓶颈，所以PolarDB-X提供XPlan机制：对于点查场景，直接传输执行计划交给DN执行。

这样的定位说明XPlan不是必须的能力，而是锦上添花的能力。目前XPlan的适用范围被限定为单张表的DQL，只支持Scan、Filter和Project算子。

XPlan在Sysbench点查上有10%以上的提升，但线上在用户的真实场景下XPlan索引错选导致的慢查询问题频发。对于PolarDB-X来说，选错索引有两种可能：基数估计错误和执行计划缓存下的倾斜索引。

基数估计错误的三个常见原因统计信息缺失、倾斜数据和关联列，学术界、工业界研究了几十年都无法解决[2]。这些问题虽然无法解决，但是很容易检测到，PolarDB-X基本策略是检测到这些问题就禁用XPlan，交给DN做局部索引选择。同样发现索引错选也是容易的。通过预先和事后的检测，希望尽量减少XPlan错选概率。

PolarDB-X的优化器与索引选择

下图是一条sql过PolarDB-X优化器的大致过程：经过RBO和CBO后生成最好的单机执行计划，并基于CBO产生的最优执行计划的代价判断当前查询是否为AP查询