PolarDB-X包含计算节点(CN)和数据节点(DN)，CN负责SQL解析、优化和执行，DN节负责数据的持久化，CN与DN之间通过RPC通信。DN 100%兼容Mysql，也是作为PolarDB-X标准版进行售卖的。
CN与DN之间RPC通信的内容其实就是标准的SQL，CN会将解析优化好的语法树转成SQL传给DN重新解析、优化。对比起来，将CN的语法树直接传给DN执行听起来就更优。
但这样其实不一定好，主要原因是作为存算分离的架构，数据都在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错选概率。
