一、OLTP + OLAP = HTAP，传统架构难以兼顾双负载

核心公式：OLTP + OLAP = HTAP。 TP 是事务处理（transaction processing），TiDB 完整支持事务能力，原生适配 OLTP 在线事务场景；AP 代表数据分析（analytics），负责海量统计查询；H 为 Hybrid 混合，HTAP 即一套数据库同时承载事务写入与数据分析。

传统方案想要实现 OLAP 分析，必须单独搭建数据仓库，数仓的表设计、底层存储和 OLTP 事务库完全割裂，根源是两类负载的优化逻辑天生冲突：

1. 索引设计冲突 OLAP 多排序、JOIN、最值查询，常大范围扫描，有序索引能显著降低 IO，索引越多越有利； OLTP 依赖索引快速定位更新、删除数据，但 Insert 写入会被索引拖累，一张表 10 个索引就要同步写 10 份数据，索引越多增删改性能越差，事务库会严控索引数量。
2. 数据块大小冲突 OLAP 偏好大容量 Block，单次 IO 读取更多数据，减少磁盘交互； OLTP 以单行读写为主，大块会产生无效 IO 浪费，更适合小尺寸数据块。

OLAP 查询本身有鲜明特征：以只读为主、极少改数据；跨行批量运算，极少单条查询；存在列亲和性，仅用到少量字段；SQL 逻辑复杂，包含多表关联、分组、聚合函数、窗口函数等。行业公认，海量分析场景最优方案是列式存储。

TiDB 原生行存引擎为 TiKV，基于 KV 结构存储行数据，适配 OLTP 业务；想要同时支撑 OLAP，则需要专属列存组件 TiFlash，依靠它实现 HTAP 混合负载能力。

二、行存 vs 列存结构对比

我们通过插入、全表聚合两种场景，直观区分行存、列存性能差异，以一张包含 ID、name、score 三列的表举例：

1. 插入操作（OLTP 写入场景） 行存：一整行数据存入同一个数据块，插入仅访问 1 个 Block，1 次 IO 即可完成，写入效率高； 列存：各列分开存储，新增一行需分别写入 3 列对应的 3 个数据块，触发 3 次 IO，写入性能弱于行存。

2. 全表聚合查询（OLAP 分析场景） 以无过滤条件统计全表平均分 AVG (score) 为例： 行存必须读取每行全部字段，访问 3 个数据块； 列存仅读取 score 单列区块，跳过所有无关字段，IO 开销大幅降低，分析场景优势明显。

除此之外，列存拥有极强压缩能力：同列数据类型统一、重复值多（如分数 0-100、性别仅少数取值），压缩倍率极高；而行存字段混杂，数据无统一规律，压缩效果很差。磁盘 IO 是数据库最大性能瓶颈，列存能大幅减少扫描数据量，相当于自带轻量化索引。

三、TiFlash 列存引擎的核心价值

TiFlash 是 TiDB 专属列式存储引擎，以 Raft Learner 角色同步 TiKV 全量数据，Learner 仅同步数据、不参与集群投票选举，不会成为 Leader；数据同步完成后自动转为列存格式。 TiDB 优化器会自动识别 SQL 类型，事务明细查询下发 TiKV 行存执行，聚合、统计类分析查询自动路由 TiFlash 列存运算，一套 SQL 引擎无缝兼容两种存储，完美实现 HTAP 混合负载。TiFlash 底层详细执行逻辑，将在 201.3 课程详细展开。