本文介紹了列存索引的技術背景、簡介以及技術架構等內容。
技術背景
MySQL生態HTAP數據庫解決方案
MySQL是一款主要面向OLTP型場景設計的開源數據庫，開源社區的研發方向側重于加強其事務處理能力。如提升單核性能、多核擴展性和增強集群能力，以提升可用性等。在處理大數據量下復雜查詢所需要的能力方面，如優化器處理子查詢的能力、高性能算子HashJoin、SQL并行執行能力等，MySQL社區一直將其放在比較低優先級上，因此，MySQL的數據分析能力提升進展緩慢。
隨著MySQL發展為世界上最為流行的開源數據庫系統，用戶在其中存儲了大量的數據，并且運行著關鍵的業務邏輯，對這些數據進行實時分析成為一個日益增長的需求。當單機MySQL不能滿足需求時，用戶尋求一個更好的解決方案。如MySQL+專用AP數據庫的搭積木方案、基于多副本的Divergent Design方法以及一體化的行列混合存儲方案等。
MySQL+專用AP數據庫的搭積木方案
該方案由兩套系統來分別滿足OLTP和OLAP型需求，在兩套系統中間通過數據同步工具進行數據的實時同步。用戶甚至可以增加一層Proxy，自動將TP型負載路由到MySQL上，將分析性負載路由到OLAP數據庫上，對應用層屏蔽底層數據庫的部署拓撲。架構圖如下：
該架構有其靈活之處。如對于TP數據庫和AP數據庫都可以各自選擇最好的方案，而且實現了TP/AP負載的完全隔離。但是其缺點也是顯而易見的。首先，在技術上需要維護兩套不同技術體系的數據庫系統，其次由于兩套系統處理機制的差異，維護上下游的數據實時一致性也非常具有挑戰性。而且存在數據同步延遲，下游AP系統存儲的經常是過時的數據，從而導致無法滿足實時分析的需求。
基于多副本的Divergent Design方法
隨著互聯網而興起的新興數據庫產品很多都兼容了MySQL協議，這些分布式數據庫產品大部分采用了分布式Share Nothing方案，其一個核心特點是使用分布式一致性協議來保障單個partition多副本之間的數據一致性。由于一份數據在多個副本之間完全獨立，因此在不同副本上使用不同格式進行存儲，來服務不同的查詢負載是一個易于實施的方案。典型的如TiDB，其從TiDB4.0開始，位于一個Raft Group中的其中一個副本上，使用列式存儲（TiFlash）來響應AP型負載，并通過TiDB的智能路由功能來自動選取數據來源。實現了一套數據庫系統同時服務OLTP型負載和OLAP型負載。
該方法在諸多Research及Industry領域的工作中都被借鑒并使用，并日益成為分布式數據領域一體化HTAP的事實標準方案。 但應用這個方案的前提是用戶需要將數據遷移到對應的NewSQL數據庫系統中，而這往往會帶來各種兼容性問題。
一體化的行列混合存儲方案
比多副本的Divergent Design方法更進一步的方案，即在同一個數據庫實例中采用行列混合存儲的方案，同時響應TP型和AP型負載。這是傳統商用數據庫Oracle、SQL Server和DB2等不約而同采用的方案。
Oracle公司在2013年發表的Oracle 12C上，發布了Database In-Memory套件，其最核心的功能為In-Memory Column Store，即通過行列混合存儲/高級查詢優化（物化表達式，JoinGroup）等技術來提升OLAP性能。
微軟在SQL Server 2016 SP1上，開始提供Column Store Indexs功能，用戶可以根據負載特征，靈活的使用純行存表、純列存表、行列混合表以及列存表+行存索引等多種模式。
IBM在2013年發布的10.5版本（Kepler）中，增加了DB2 BLU Acceleration組件，通過列式數據存儲配合內存計算以及DataSkipping技術，大幅提升分析場景的性能。
三家領先的商用數據庫廠商，均同時采用了行列混合存儲結合內存計算的技術路線。列式存儲由于有更好的IO效率（壓縮、DataSkipping、列裁剪）以及CPU計算效率（Cache Friendly），因此要達到最極致的分析性能必須使用列式存儲，而列式存儲中由于索引稀疏導致索引精準度問題決定了它不可能成為TP場景的存儲格式。因此，行列混合存儲成為一個必選方案。但在行列混合存儲架構中，行存索引和列存索引在隨機更新數據時存在性能鴻溝，必須借助DRAM的低讀寫延時來彌補列式存儲更新效率低的缺陷。因此，在低延時在線事務處理和高性能實時數據分析兩大前提下，行列混合存儲結合內存計算成為最優方案。
對比上述三種方案，從組合搭積木的方案到Divergent Design方法，再到一體化的行列混合存儲方案。其集成度越來越高，用戶的使用體驗也越來越好。但是其對內核工程實現上的挑戰也越來越大。而基礎軟件的作用就是將復雜留給自己，將簡單留給用戶。因此，一體化的行列混合存儲方案更為符合技術發展趨勢。
PolarDB MySQL AP能力的演進
PolarDB MySQL版能力棧與開源MySQL類似，長于TP但AP能力較弱。由于PolarDB提供了單個集群最大500 TB的存儲能力，同時其事務處理能力遠超用戶自建MySQL。因此，PolarDB用戶傾向于在單個集群上存儲更多的數據，同時會在這些數據上進行一些復雜的聚合查詢。借助于PolarDB一寫多讀架構，用戶可以根據實際需求增加多個RO節點以運行復雜查詢，從而避免分析型查詢對TP負載的干擾。
MySQL架構在AP場景的缺陷
MySQL架構在執行復雜查詢時性能差有多個方面的原因。對比專用的OLAP系統，其性能瓶頸體現在以下方面：
MySQL的SQL執行引擎基于流式迭代器模型（Volcano Iterator）實現。該架構在工程實現上依賴大量深層次的嵌套函數及虛函數，在處理海量數據時，這種架構會影響CPU流水線的Pipeline效率，導致CPU Cache效率低下。同時，Iterator執行模型也無法充分使用CPU提供的SIMD指令來做執行加速。
執行引擎只能串行執行，無法發揮多核CPU的并行能力。官方從MySQL 8.0開始，在
count(*)等基本查詢上增加了并行執行能力，但構建復雜SQL語句的并行執行能力依然任重道遠。MySQL最常用的存儲引擎都是按行存儲，在按列進行海量數據分析時，按行從磁盤讀取數據存在非常大的IO帶寬浪費。其次，行式存儲格式在處理大量數據時會大量拷貝不必要的列數據，對內存讀寫效率也存在沖擊。
PolarDB并行查詢突破CPU瓶頸
并行查詢框架（Parallel Query）可以在查詢數據量到達一定閾值時，自動啟動并行執行。在存儲層將數據分片到不同的線程上，由多個線程并行計算，并將結果流水線匯總到總線程。最后，總線程做簡單歸并返回給用戶，以提高查詢效率。 
并行查詢突破了單核執行性能的限制，利用多核CPU的并行處理能力，使得部分SQL查詢耗時成指數級下降。
PolarDB列式存儲
并行執行框架突破了CPU擴展能力的限制，帶來了顯著的性能提升。然而，受限于行式存儲及行式執行器的效率限制，單核執行性能存在天花板，其峰值性能依然與專用的OLAP系統存在差距。要更進一步的提升分析性能，則需要引入列式存儲：
在分析場景，經常需要訪問某個列的大量記錄，而列存按列拆分存儲的方式會避免讀取不需要的列。其次，列存會將相同屬性的列連續保存，其壓縮效率也遠超行存，通常可以達到10倍以上。列存中大塊存儲的結構，結合MIN/MAX等粗糙索引信息可以實現大范圍的數據過濾。所有這些行為都極大的提升了IO的效率。在存儲計算分離架構下，減少通過網絡讀取的數據量可以對查詢處理的響應時間帶來立竿見影的提升。
列式存儲同樣能提高CPU在處理數據時的執行效率。首先，列存的緊湊排列方式可提升CPU訪問內存的效率，減少由L1/L2 Cache miss導致的執行停頓時間。其次，在列式存儲上可以應用SIMD技術來進一步提升單核吞吐能力。
簡介
PolarDB In-Memory Column Index功能提供了列式存儲以及內存計算能力，讓用戶可以在一套數據庫上同時運行TP和AP型混合負載，在保證現有PolarDB優異的OLTP性能的同時，大幅提升了在大數據量上運行復雜查詢的性能。原理圖如下：
列存索引使用行列混合存儲技術。同時，結合PolarDB基于共享存儲一寫多讀的架構特征，其包含如下幾個關鍵的技術創新點：
存儲引擎（InnoDB）支持存儲列式索引（Columnar Index），用戶可以通過DDL語句為一張表中的全部列或者部分列創建列索引，列索引采用列壓縮存儲，其存儲空間消耗會遠小于行存格式。默認列索引會全部常駐內存以實現最大化分析性能。但是，當內存不夠時也支持將其持久化到共享存儲中。
在SQL執行器層，重寫了一套面向列存的執行器引擎框架（Column-oriented），該執行器框架充分利用列式存儲的優勢，如以4096行的一個Batch為單位訪問存儲層的數據，使用SIMD指令提升CPU單核心處理數據的吞吐，所有關鍵算子均支持并行執行。在列式存儲上，新的執行器對比MySQL原有的行存執行器有數量級的性能提升。
支持行列混合執行的優化器框架，該優化器框架會根據下發的SQL語句能否在列索引上執行來覆蓋查詢，并且其所依賴的函數及算子能否在列式執行器中執行來決定是否啟動列式索引。優化器會同時對行存執行計劃和列存執行計劃做代價估算，并選中代價較低的執行計劃。
用戶可以使用集群中的一個RO節點作為分析型節點，在該RO節點上配置生成列存索引，復雜查詢運行在列存索引上并使用所有可用CPU的計算能力，在獲得最大執行性能的同時不影響該集群上的TP型負載的可用內存和CPU資源。
以上幾個關鍵技術的結合，使得PolarDB成為了一個真正的HTAP數據庫系統。
技術架構
行列混合優化器
PolarDB有一套面向行存的優化器組件，引擎層支持列存功能之后，此部分需要進行功能增強。優化器需要能夠判斷一個查詢應該被調度到行存執行還是列存執行。基于此，列存索引通過一套白名單機制和執行代價計算框架來完成此項任務。系統保證對支持的SQL語句進行加速查詢，同時兼容運行不支持的SQL。
如何實現100%的MySQL兼容性
通過一套白名單機制來實現兼容性。 使用白名單機制是基于如下幾點考量。
系統可用資源（主要是內存）限制。
一般情況下，不會為數據庫中全部表的所有列上都創建列索引。當一條查詢語句中使用到的列沒有在列存中存在時，其不能在列存上執行。
性能。
重寫一套面向列存的SQL執行引擎，包括所有的物理執行算子和表達式計算，其所覆蓋的場景相對MySQL原生行存能夠支持的范圍有欠缺。當下發的SQL語句中包含一些列存索引不支持的算子片段或者列類型時，需要能夠識別攔截并切換回行存執行。
目前，白名單規則校驗的內容包含SQL語句中的數據類型、算子、計算表達式以及其他場景。其他場景如不支持multi statement等。
MySQL已經發展了數十年，其支持的各種列類型和SQL語法非常豐富。在IMCI中，初期重點優化在分析型查詢語句中最常見的SQL性能問題。即使適用場景有所限制，IMCI能夠運行的SQL語法對MySQL功能的兼容性也遠超絕大部分OLAP系統。對于那些不能在列存上執行的SQL，則直接回退到MySQL原生執行引擎，因此實現了100%的MySQL兼容。
查詢計劃轉換
Plan轉換的目的是將MySQL的原生邏輯執行計劃表示方式AST轉換為IMCI的Logical Plan。在生成IMCI的Logical Plan之后，會經過Optimize過程，繼而生成Physical Plan。
Plan轉換只需要遍歷整個執行計劃樹，將MySQL優化后的AST轉換成以relation operator為節點的樹狀結構即可。在這個過程中，會進行類型的隱式轉換，以兼容MySQL靈活的類型系統。
Plan轉換生成的是一個等價的Logical Plan，其需要被轉換成Physical Plan才能被執行器執行。目前IMCI的Optimizer比較簡單，除了一些基本的執行計劃優化（如決策是使用HashJoin還是使用NestedLoop Join）外，Optimizer最主要的作用是將目前IMCI執行器不支持的子查詢轉換為一個等價的Join操作。
兼顧行列混合執行的優化器
由于存在行存和列存兩套執行引擎，優化器在選擇執行計劃時有了更多的選擇，其可以對比行存執行計劃的Cost和列存執行計劃的Cost，并使用代價最低的執行計劃。
在PolarDB中，除原生MySQL的行存串行執行外，還有能夠發揮多核計算能力的基于行存的Parallel Query功能。因此，實際優化器會在行存串行執行、行存Parallel Query、以及IMCI三個之中選擇其一。在目前的迭代階段，優化器按如下的流程執行：
執行SQL的Parse過程并生成LogicalPlan，然后調用MySQL原生優化器，并執行優化操作（join order等）。同時該階段獲得的邏輯執行計劃會轉給IMCI的執行計劃編譯模塊，并嘗試生成一個列存的執行計劃（此處可能會被白名單攔截并回滾回行存）。
PolarDB的Optimizer會根據行存計劃，計算得出一個面向行存的執行Cost。如果此Cost超過一定閾值，則會嘗試下推到IMCI執行器使用IMCI_Plan執行。
如果IMCI無法執行此SQL，則PolarDB會嘗試編譯出一個Parallel Query的執行計劃并執行。如果無法生成PQ的執行計劃，則說明IMCI和PQ均無法執行此SQL，則回滾回行存執行。
上述策略是基于這樣一個判斷，從執行性能上進行對比：行存串行執行 < 行存并行執行 < IMCI。 對比SQL兼容性，IMCI < 行存并行執行 < 行存串行執行。但是實際情況會更加復雜，例如：某些情況下，基于行存有序索引覆蓋的并行Index Join會比基于列存的Sort Merge join有更低的Cost。按照當前策略，則會選擇IMCI列存執行。
面向列式存儲的執行引擎
IMCI是一套面向列存優化并完全獨立于現有MySQL行式執行器的執行引擎。重寫執行器的目的是為了消除現有行存執行引擎在執行分析型SQL時效率低的兩個關鍵瓶頸點，即按行訪問導致的虛函數訪問開銷以及無法并行執行。
向量化并行執行器
IMCI執行器引擎使用經典的火山模型，但是借助了列存存儲以及向量執行來提升執行性能。
火山模型中，SQL生成的語法樹所對應的關系代數中，每一種操作會抽象為一個Operator，執行引擎會將整個SQL構建成一個Operator樹，查詢樹自頂向下調用Next()接口，數據則自底向上被拉取處理。該方法的優點是其計算模型簡單直接，通過把不同物理算子抽象成一個個迭代器。每一個算子只關心自己內部的邏輯即可，使得各個算子之間的耦合性降低，從而比較容易寫出一個邏輯正確的執行引擎。
在IMCI執行引擎中，每個Operator也使用迭代器函數來訪問數據，但不同的是每次調用迭代器會返回一批數據，而不是一行，可以認為這是一個使用了向量化模式的火山模型。
串行執行受制于單核計算效率、訪存延時、IO延遲等限制，執行能力有限。而IMCI執行器在幾個關鍵物理算子（Scan/Join/Agg等）上均并行執行。除物理算子需要支持并行外，IMCI的優化器也支持生成并行執行計劃，優化器在確定一個表的訪問方式時，會根據需要訪問的數據量來決定是否啟用并行執行，如果確定啟用并行執行，則會參考一系列狀態數據（包括當前系統可用的CPU/Memory/IO資源、目前已經調度和在排隊的任務信息、統計信息、query的復雜程度、用戶可配置的參數等）。 根據這些數據會計算出一個推薦的DOP值給一個算子，而一個算子內部會使用相同的DOP。同時，DOP也支持用戶使用Hint進行設定。
基于以上兩點優化思路，重新實現了所有物理執行算子，包括TableScan、HashJoin、NestedLoopJoin、Groupby等。下面以HashJoin為例展示執行器的并行化及向量化加速效果。在IMCI中，HashJoin按如下流程執行：
向量化執行解決了單核執行效率低的問題，而并行執行突破了單核的計算瓶頸。二者結合使得IMCI執行速度相比傳統MySQL行式執行有了數量級的提升。
向量化表達式體系
AP型場景，SQL中經常會包含很多涉及到一個或者多個值、運算符和函數組成的計算過程，這都是屬于表達式計算的范疇。表達式的求值是一個計算密集型的任務，因此，表達式的計算效率是影響整體性能的一個關鍵的因素。
傳統MySQL的表達式計算體系以一行為一個單位的逐行運算，一般稱其為迭代器模型實現。由于迭代器對整張表進行了抽象，整個表達式實現為一個樹形結構。但是，這種抽象會同時帶來性能上的損耗，因為在迭代器進行迭代的過程中，每一行數據的獲取都會引發多層的函數調用。同時，逐行地獲取數據會帶來過多的 I/O，對緩存也不友好。MySQL采用樹形迭代器模型，是受到存儲引擎訪問方法的限制，導致其很難對這些計算復雜的邏輯進行優化。
而在列存格式下，由于每一列的數據都單獨順序存儲，涉及到某一個特定列上的表達式計算過程都可以批量進行。對每一個計算表達式，其輸入和輸出都以Batch為單位，在Batch的處理模式下，計算過程可以使用SIMD指令進行加速。
向量化表達式的關鍵優化點：
充分利用列式存儲的優勢，使用分批處理的模型代替迭代器模型，使用SIMD指令重寫了大部分常用數據類型的表達式內核實現。例如，所有數字類型（int、decimal、double）的基本數學運算（+、 -、*、/、abs），全部都使用對應的SIMD指令實現。在AVX512指令集的加持下，單核運算性能數倍提升。
采用了與PostgreSQL類似表達式實現方法：在SQL編譯及優化階段，IMCI的表達式以一個樹形結構來存儲（與現有行式迭代器模型的表現方法類似）。但是，在執行之前會對該表達式樹進行一個后序遍歷，將其轉換為一維數組來存儲，在后續計算時只需要遍歷該一維數組結構即可以完成運算。由于消除了樹形迭代器模型中的遞歸過程，計算效率更高。同時該方法對計算過程提供簡潔的抽象，將數據和計算過程分離，適合并行計算。
行列混合存儲
事務型應用和分析型應用對存儲引擎有著截然不同的要求，前者要求索引可以精確定位到每一行并支持高效的增刪改操作，而后者則需要支持高效批量掃描處理。這兩個場景對存儲引擎的設計要求完全不同，有時甚至互相矛盾。因此，設計一個一體化的存儲引擎能同時服務OLTP型和OLAP型負載非常具有挑戰性。目前市場上HTAP存儲引擎做的比較好的只有幾家有幾十年研發積累的大型企業，如Oracle (In-Memory Column Store）、Sql Server(In Memory Column index）、DB2（BLU)等。TiDB只能通過將多副本集群中的一個副本調整為列存來支持HTAP需求。
一體化的HTAP存儲引擎一般使用行列混合的存儲方案，即引擎中同時存在行存和列存，行存服務于TP，列存服務于AP。相比于部署獨立一套OLTP數據庫加一套OLAP數據庫來滿足業務需求，單一的HTAP引擎具有如下的優勢：
行存數據和列存數據具有實時一致性，能滿足很多苛刻的業務需求，所有數據寫入即可見于分析型查詢。
低成本。用戶可以非常方便的指定哪些列甚至一張表的哪個范圍的存儲為列存格式。全量數據繼續以行存存儲。
管理運維方便，用戶無需關注數據在兩套系統之間同步及數據一致性問題。
PolarDB采用了和Oracle、Sql Server等商用數據庫類似的行列混合存儲技術，即In-Memory Column Index：
建表時可以指定部分表或者列為列存格式，或者對已有的表可以使用
ALTER TABLE語句為其增加列存屬性，分析型查詢會自動使用列存格式來進行查詢加速。列存數據默認以壓縮格式存儲在磁盤上，并可以使用In-Memory Column Store Area來做緩存并加速查詢，傳統的行格式依然保存在Buffer Pool中供OLTP型負載使用。
所有事務的增刪改操作都會實時反饋到列存存儲，保證了事務級別的數據一致性。
實現一個行列混合的存儲引擎非常困難，但是在InnoDB這樣一個成熟的面向OLTP負載優化的存儲引擎中增加列存，又面臨不同的情況：
滿足OLTP業務的需求是第一優先級。因此，增加列存不能對TP性能有太大影響。這要求維護列存必須足夠輕量，必要時需要犧牲AP性能來維持TP性能。
列存的設計無需考慮事務并發場景下對數據的影響，以及數據的unique check等問題，這些問題在行存系統中已經被解決，而這些問題對ClickHouse等單獨的列存引擎來說，非常難以處理。
由于有一個久經考驗的行存系統的存在，列存系統出現任何問題，都可以切換回行存系統響應查詢請求。
上述條件可謂有利有弊，這也影響了對整個行列混合存儲的方案設計。
表現為Index的列存
在MySQL插件式的存儲引擎框架下，增加列存支持最簡單的方案是實現一個單獨的存儲引擎，如Inforbright以及MarinaDB的ColumnStore都采用了這種方案。而PolarDB采用了將列存實現為InnoDB的二級索引方案，主要基于如下幾點考量：
InnoDB原生支持多索引，Insert、Update和Delete操作都會以行粒度apply到Primary Index和所有的Secondary Index上，并且保證事務。將列存實現為一個二級索引可以復用這套事務處理框架。
在數據編碼格式上，二級索引的列存可以和其他行存索引使用完全一樣的格式，直接內存拷貝即可，不需要考慮charset和collation等信息。
二級索引操作非常靈活，可以在建表時指定索引所包含的列，也可以后續通過DDL語句對一個二級索引中包含的列進行增加或者刪除操作。例如，用戶可以將需要分析的int、float和double列加入列索引，而對于一般只需要點查但是又占用大量空間的text和blob字段，則可以保留在行存中。
崩潰恢復過程可以復用InnoDB的Redo事務日志模塊，與現有實現無縫兼容。同時也方便PolarDB的物理復制過程，支持在獨立RO節點或者Standby節點上生成列存索引提供分析服務。
二級索引與主表有一樣的生命周期，方便管理。
如上圖所示，在PolarDB中，所有Primary Index和Secondary Index都實現為一個B+Tree。而列索引在定義上是一個Index，但其實是一個虛擬的索引，用于捕獲對該索引覆蓋列的增刪改操作。
對于上面的表，其主表（Primary Index）包含（C1、C2、C3、C4、C5） 5列數據， Secondary Index索引包含（C2、C1）兩列數據，在普通二級索引中，C2與C1編碼成一行保存在B+tree中。而其中的列存索引包含（C2、C3、C4）三列數據。在實際物理存儲時，會對三列進行拆分獨立存儲，每一列都會按寫入順序轉成列存格式。
列存實現為二級索引的另一個好處是執行器的工程實現非常簡單，在MySQL中已經存在覆蓋索引的概念，即一個查詢所需要的列都在一個二級索引中存儲，則這個二級索引中的數據滿足查詢需求，使用二級索引相對于使用Primary Index可以極大減少讀取的數據量進而提升查詢性能。當一個查詢所需要的列都被列索引覆蓋時，借助列存的加速作用，可以數十倍甚至數百倍的提升查詢性能。
列存數據組織
對Column Index中的每一列，其存儲都使用了無序且追加寫的格式。結合標記刪除及后臺異步compaction實現空間回收。其具體實現上有如下幾個關鍵點：
列索引中記錄按RowGroup進行組織（目前每個RowGroup包含64K行），每個RowGroup中不同的列會各自打包形成DataPack。
每個RowGroup都采用追加寫，分屬每個列的DataPack也是采用追加寫模式。對于一個列索引，只有Active RowGroup負責接受新的寫入。當該RowGroup寫滿之后即凍結，其包含的所有Datapack會轉為壓縮格保存到磁盤上，同時記錄每個數據塊的統計信息便于過濾。
列存RowGroup中每新寫入一行都會分配一個RowID用于定位，屬于一行的所有列都可以用該RowID計算定位，同時系統維護PK到RowID的映射索引，以支持后續的刪除和修改操作。
更新操作采用標記刪除的方式，對于刪除操作直接設置BitMap即可。對于更新操作，首先根據RowID計算出其原始位置并設置刪除標記，然后在ActiveRowGroup中寫入新的數據版本。
當一個RowGroup中的無效記錄超過一定閾值，則會觸發后臺異步compaction操作，其作用一方面是回收空間，另一方面可以讓有效數據存儲更加緊湊，提升分析型查詢單的效率。
采用這種數據組織方式，一方面滿足了分析型查詢按列進行批量掃描過濾的要求。另一方面對于TP型事務操作影響非常小，寫入操作只需要按列追加寫到內存即可，刪除操作只需要設置一個刪除標記位。而更新操作則是一個標記刪除附加一個追加寫。列存在支持事務級別更新的同時，幾乎不影響OLTP的性能。
全量及增量行轉列
以下兩種情況會執行行轉列操作：
第一種情況：使用DDL語句對部分列創建列索引（對一張已存在的表有分析型需求），此時需要掃描全表數據以創建列索引。
第二種情況：在事務操作過程中對涉及到的列執行行轉列。
對于全表行轉列的情形，使用并行掃描的方式對InnoDB中的Primary Key進行掃描，并依次將所有涉及到的列轉換為列存形式，該操作的速度非常快，其基本僅受限于服務器可用的IO吞吐速度和CPU資源。該操作是一個online-DDL過程，不會阻塞在線業務的運行。
在一張表上建立列索引之后，所有的更新事務將會同步更新行存和列存數據，以保證二者的事務一致性。下圖演示了開啟和關閉IMCI功能的差異性。
未開啟IMCI功能時，事務對所有行的更新都會先加鎖，然后在對數據頁進行修改，在事務提交之前會對所有加鎖的記錄一次性釋放鎖。
開啟IMCI功能之后，事務系統會創建一個列存更新緩存，在所有數據頁被修改的同時，會記錄所涉及到的列存的修改操作，在事務結束并釋放鎖之前，該緩存會應用到列存系統。
對于一般的OLTP型請求，最后的內存數據頁更新只占事務操作過程的很少一部分時間，因此此方法對TP型事務時延的影響非常小。對于操作了非常多的行的大事務，則會直接將其對列索引的更新實時應用到列存存儲，但是在事務提交之前不對外可見，也保證了大事務的提交延時增加在一個非常小的時間范圍。同時為了更進一步的降低對TP性能的影響，當AP型查詢對數據的實時性要求不高時, 列索引支持異步應用對列存的更新操作。
列存存儲提供了與行存一樣的事務隔離級別。對于每個寫操作，RowGroup中的每一行都會記錄修改該行的事務編號，而對于DeleteBitMap，每個標記刪除操作也會記錄該標志位的事務編號。借助寫入事務號和刪除事務號，AP型查詢可以用非常輕量級的方式獲得一個全局一致性的快照。
列索引粗糙索引
由前述列舉的存儲格式可以看出，IMCI中所有的Datapack都采用無序且追加寫的方式，因此無法像InnoDB的普通有序索引那樣，可以精準的過濾掉不符合要求的數據。在IMCI中，借助統計信息來進行數據塊過濾，以此來達到降低數據訪問單價的目的。
在每個Active Datapack終結寫入的時候，會預先進行計算，并生成Datapack所包含數據的最小值、最大值、數值的總和、空值的個數和記錄總條數等信息。所有這些信息會維護在DataPacks Meta元信息區域并常駐內存。由于凍結的Datapack中還會存在數據的刪除操作，因此統計信息的更新維護會放到后臺完成。
對于查詢請求，會根據查詢條件將Datapacks分為相關、不相關、可能相關三大類，從而減少實際的數據塊訪問。而對于一些聚合查詢操作，如count和sum等，可以通過預先計算好的統計值進行簡單的運算得出，這些數據塊甚至都不需要進行解壓。
采用基于統計信息的粗糙索引方案，對于一些需要精準定位部分數據的查詢并不是很友好。但是在一個行列混合存儲引擎中，列索引只需要輔助加速那些會涉及到大量數據掃描的查詢，在這個場景下使用列存索引會具有顯著的優勢。而對于那些只會訪問到少量數據的SQL，優化器通常會基于代價模型計算得出基于行存而得到的一個成本更低的方案。
行列混合存儲下的TP和AP資源隔離
行列混合存儲可以在一個集群中同時支持AP型查詢和TP型查詢。但很多業務有很高的OLTP型負載，而突發性的OLAP型負載可能干擾到TP型業務的響應時延。因此負載隔離在HTAP數據庫中是一個必須支持的功能。借助一寫多讀架構，可以非常方便地對AP型負載和TP型負載進行隔離。在PolarDB技術架構下，有如下幾個部署方式：
第一種方式：在RW上開啟行列混合存儲，此種部署模式可以支持輕量級的AP查詢，以TP負載為主，且AP型請求比較少時可以采用。或者使用PolarDB進行報表查詢，且數據來自批量數據導入的場景。
第二種方式：RW支持OLTP型負載，并啟動一個AP型RO開啟行列混合存儲以支持查詢，此種部署模式下CPU資源可以實現100%隔離，同時該AP型RO節點上的內存可以100%分配給列存存儲和執行器。但是，由于使用相同的共享存儲，因此在IO上會相互產生一定影響。
第三種方式：RW和RO均支持OLTP型負載，在單獨的Standby節點開啟行列混合存儲以支持AP型查詢，由于Standby是使用獨立的共享存儲集群，這種方案在第二種方案支持CPU和內存資源隔離的基礎上，還可以實現IO資源的隔離。
除上述部署架構上的不同，和可以支持的資源隔離不同之外。在PolarDB內部對于一些需要使用并行執行的大查詢，支持動態并行度調整（Auto DOP），這個機制會綜合考慮當前系統的負載以及可用的CPU和內存資源，對單個查詢所用的資源進行限制，以避免單個查詢消耗的資源太多，影響其他請求的處理。
OLAP性能
詳情請參見列存索引（IMCI）性能。