TiDB分布式HTAP数据库行列混合引擎与实时分析查询优化

TiDB HTAP架构与行列双引擎设计

TiDB作为开源分布式HTAP数据库，核心设计目标是同一集群内同时承载OLTP事务处理和OLAP分析查询。传统架构中这两类负载通常由独立系统承担——MySQL/PostgreSQL处理事务，ClickHouse/StarRocks处理分析，中间通过ETL或CDC同步数据，延迟和运维复杂度是主要痛点。

TiDB 7.x的HTAP架构由两个存储引擎协同工作：TiKV行存储引擎处理事务读写，TiFlash列存储引擎加速分析查询。两引擎共享同一份Raft日志流，数据通过Raft learner协议异步复制到TiFlash，保证事务一致性。行存和列存的数据在物理上独立存储，逻辑上对用户透明——SQL优化器自动根据查询特征选择最优执行路径。

TiFlash列存储引擎内部结构

TiFlash基于ClickHouse的DeltaTree存储引擎改造，核心数据结构包括：

DTSegment：数据段，每个段包含一个稳定数据区和多个增量数据区。稳定区数据按列存储并压缩，增量区接纳实时写入。段内数据按主键排序，支持高效的范围扫描和主键查找。

Delta Cache：写入缓冲区，新写入的数据先进入Delta Cache，累积到阈值后刷入增量区。这种设计使TiFlash在保持列存高压缩比的同时，对实时写入有良好的吞吐能力。

DMFile：磁盘文件格式，每列独立存储，支持LZ4/ZSTD压缩。数值列的压缩率通常在5:1到10:1之间，字符串列的压缩率取决于数据重复度。

TiFlash节点通过Raft Learner角色订阅TiKV的变更日志，数据同步延迟通常在百毫秒到秒级。对于强一致性分析查询，可通过SET tidb_isolation_read_engines = "tiflash"强制读取TiFlash，或在SQL hint中使用/*+ read_from_storage(tiflash[table_name]) */指定。

行列混合执行计划选择

TiDB优化器在生成执行计划时评估行存和列存两种路径的代价，选择成本更低的方案。关键判断逻辑：

纯点查和窄范围扫描走TiKV行存。行存对主键或索引点查的效率远高于列存，单行读取只需一次IO。

聚合分析和宽表扫描走TiFlash列存。列存只读取查询涉及的列，避免无关列的IO开销；列式压缩减少磁盘读取量；向量化执行引擎对批量数据处理效率高。

混合场景（OLTP查询中包含少量聚合）通过optimizer_switch控制：

SET SESSION tidb_opt_agg_push_down = 1;

SET SESSION tidb_allow_batch_cop = 1;

agg_push_down将聚合操作下推到存储层执行，减少网络传输数据量。allow_batch_cop允许TiFlash以批量模式执行Coprocessor请求，提升分析查询的并发效率。

查看优化器的引擎选择决策：

EXPLAIN ANALYZE SELECT region, SUM(amount) FROM orders GROUP BY region;

执行计划中的Storage列显示实际使用的存储引擎，如果出现TiKV而预期是TiFlash，需检查统计信息是否过期或是否被hint覆盖。

实时分析查询性能调优

TiDB HTAP场景下的性能调优围绕列存引擎和查询执行两个维度展开。

TiFlash副本数配置：至少2个副本保证高可用，分析查询负载大时增加到3-4个。副本数通过Placement Rules控制：

ALTER DATABASE analytics SET PLACEMENT POLICY = 'tiflash_2replicas';

Region副本调度：大表Region数量过多时，TiFlash的Raft learner同步开销增大。通过Region Merge减少Region数量：

SET config pd scheduler-max-merge-region-size = 96;

SET config pd scheduler-max-merge-region-keys = 960000;

列存数据压缩优化：对历史分区使用更高压缩比，降低存储成本：

ALTER TABLE orders MODIFY COLUMN data_compression = 'zstd' PARTITION p_before_2025;

内存控制：TiFlash的查询内存使用上限默认为单查询10GB，大分析查询可能超限。调整方式：

SET config tiflash max_memory_usage = 20000000000; -- 20GB

SET config tiflash max_memory_usage_for_all_queries = 80000000000; -- 80GB

spill to disk机制在内存不足时自动将中间结果溢写到磁盘，避免OOM。但溢写会显著降低查询速度，生产环境应通过合理设置内存上限和并发度来尽量避免。

典型场景部署架构

电商实时报表场景的推荐部署架构：

OLTP节点：3个TiKV节点（16C/64G/NVMe SSD），承载订单写入和查询。TiFlash节点：2个TiFlash节点（32C/128G/NVMe SSD + HDD冷数据），承载报表和实时大屏分析。PD节点：3个PD节点（4C/8G），与TiDB SQL节点混合部署。TiDB SQL节点：3个TiDB节点（8C/32G），根据查询类型设置read_from_storage hint。

监控核心指标：TiFlash同步延迟（raft_learn_duration）、列存段数量（segment_count）、查询执行耗时P99、内存使用率。告警阈值：同步延迟超过30秒、TiFlash节点CPU超过85%、查询耗时P99超过5分钟。