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錯選概率。
