PolarDB MySQL版重磅推出了列存索引（IMCI）特性。
简介
当前主要面向OLTP场景，广泛应用于在线业务，日常产生大量的数据。但是，基于行存的查询性能并不能满足所有应用场景的需求。通常情况下，为了实现复杂分析型查询，需要将数据从PolarDB MySQL版导出，然后导入到外部专用的OLAP系统中再进行分析查询。这样一来，需要使用两套数据库系统，架构复杂性、运维工作量和成本都会大大增加。
PolarDB MySQL版重磅推出的列存索引（In-Memory Column Index，简称IMCI）面向OLAP场景大数据量复杂查询。通过列存索引，PolarDB MySQL版实现了一体化的实时事务处理和实时数据分析的能力，成为一站式HTAP数据库产品解决方案。通过一套数据库系统，即可满足业务的OLTP及OLAP需求。
版本要求
企业版集群，集群版本需满足以下条件之一：
PolarDB MySQL版8.0.1版本，且修订版本为8.0.1.1.22及以上。
PolarDB MySQL版8.0.2版本，且修订版本为8.0.2.2.12及以上。
标准版集群，CPU架构需为X86，集群版本需满足以下条件之一：
PolarDB MySQL版8.0.1版本，且修订版本为8.0.1.1.38及以上。
PolarDB MySQL版8.0.2版本，且修订版本为8.0.2.2.19及以上。
实现形态
为了实现OLAP和OLTP的计算资源隔离，当前仅支持在只读节点上实现列存索引，即OLAP查询请求只发给只读节点，而不会发给主节点。至于OLAP查询请求是发给只读行存节点，还是只读列存节点，可根据行存/列存分流方案进行配置。
技术原理
列存索引特性在PolarDB MySQL版中的功能架构图如下：
从以上架构图可以看到，PolarDB MySQL版从存储引擎、执行算子、优化器三个层面设计了列存索引的特性：
存储引擎：支持实时事务级别一致性的行列混合存储；
执行算子：面向列存的向量化并行执行算子，支持极速的单表和多表查询；
SQL Parser/优化器：面向行列混合存储的CBO优化器，可以根据代价自动选择行存或者列存执行查询请求；
在此架构下，PolarDB MySQL版实现了100%兼容MySQL协议的基础上，同时获得数个数量级的查询加速效果。
核心优势
PolarDB MySQL版依托列存索引特性，具备如下优势：
100%兼容MySQL：列存具有与MySQL一致的数据类型系统，支持灵活的类型转换，100%兼容MySQL协议；
优秀的HTAP性能：PolarDB在OLTP方面本身具备良好性能。列存索引使其OLAP性能也与专用的OLAP数据库系统处于同一水平；
行列混合存储，降低成本：同时支持行存储和列存储两种格式，且实时保证行列的事务级一致。列存更具有低成本的优势。
适用场景
PolarDB MySQL版的列存索引特性提供了一站式HTAP产品体验，可以应用于多种业务场景：
对在线数据有实时数据分析需求的场景，如实时报表；
专用数据仓库场景：依托PolarDB提供的海量数据存储能力，汇聚多个上游数据源，将其作为专用数据仓库使用；
ETL数据加速计算场景：依托PolarDB基于列存索引提供的强大而灵活的计算能力，在PolarDB中使用SQL来实现ETL功能。
性能提升情况
列存索引功能对SQL查询操作有明显的加速作用，查询性能甚至可以提升百倍。接下来我们以标准TPC-H测试的数据表和SQL为例，体验列存索引对查询的加速效果。
测试方法：TPC-H是业界常用的一套基准，由TPC委员会制定发布，用于评测数据库的分析型查询能力。TPC-H查询包含8张数据表、22条复杂的SQL查询，大多数查询包含若干表Join、子查询和Group by聚合等。
本文的TPC-H的实现基于TPC-H的基准测试，并不能与已发布的TPC-H基准测试结果相比较，本文中的测试并不符合TPC-H基准测试的所有要求。
数据量：100 GB。
测试结果：
开启列存索引前后性能对比
下图展示了开启列存索引前后分别执行TPC-H的22条查询语句的查询响应时间的对比。
开启列存索引后与ClickHouse性能对比
下图展示了开启列存索引后，执行TPC-H的21条查询语句（Q21除外，ClickHouse不支持）的查询响应时间，与相同数据量和数据结构的ClickHouse数据库的对比。
结论：
列存索引对大多数的复杂查询操作都有加速作用，查询性能提升非常明显，甚至可达到百倍。
与传统OLAP数据库ClickHouse相比：PolarDB MySQL版开启列存索引后，与ClickHouse性能相比各有优劣。其中在单表Scan/AGG、Join等场景中表现突出。未来的列存索引特性将在聚合加速、窗口函数等方面持续优化和突破。