TiDB HTAP架构部署实战：TiFlash列存与行列混合查询

TiDB HTAP（Hybrid Transactional/Analytical Processing）架构在国产数据库领域提供了兼顾OLTP和OLAP的方案。传统架构中事务处理走行存储引擎，分析查询走列存储引擎，数据通过ETL同步，延迟和一致性成本高。TiDB的TiFlash列存副本通过Raft协议实时同步行存数据，实现事务和分析在同一系统内完成。数据备份恢复和高可用架构设计中，TiFlash的Raft Learner角色保证了行存与列存的数据一致性。

TiDB HTAP架构与TiFlash存储引擎原理

TiDB集群由三个核心组件构成：TiDB Server（SQL层）、TiKV（行存储引擎）、TiFlash（列存储引擎）。TiKV使用单节点Raft Group保证行存数据的强一致性，TiFlash以Raft Learner角色异步接收数据变更写请求。

数据同步链路：

TiDB Server
    |
    v
TiKV (Leader/Follower, Row Store)
    |
    | Raft Log Replication
    v
TiFlash (Learner, Column Store)
    |
    | Delta Tree Engine
    v
列存数据（实时可查询）

TiFlash内部使用Delta Tree引擎，数据分为Stable层（列式存储，类似ClickHouse的MergeTree）和Delta层（行式增量数据）。查询时引擎自动合并Stable和Delta层结果，保证读取到最新已提交数据。Delta层达到阈值后触发后台compaction合并到Stable层。

部署TiFlash节点与集群配置

使用tiup部署含TiFlash的TiDB集群，以下是最小化拓扑文件：

# topology.yaml
server_configs:
  tidb:
    log.level: "info"
    performance.txn-total-size-limit: 104857600
  tikv:
    storage.scheduler-worker-pool-size: 4
    raftdb.defaultcf.compression: "lz4"
  tiflash:
    storage.main.dir: ["/data1/tiflash", "/data2/tiflash"]
    storage.latest.dir: ["/data1/tiflash"]
    logger.loglevel: "info"

tidb_servers:
  - host: 10.0.1.10
  - host: 10.0.1.11

tikv_servers:
  - host: 10.0.1.20
    port: 20160
    status_port: 20180
  - host: 10.0.1.21
    port: 20160
    status_port: 20180
  - host: 10.0.1.22
    port: 20160
    status_port: 20180

tiflash_servers:
  - host: 10.0.1.30
    tcp_port: 9000
    flash_service_port: 3930
    flash_proxy_port: 20170
    flash_status_port: 20292
  - host: 10.0.1.31
    tcp_port: 9000
    flash_service_port: 3930
    flash_proxy_port: 20170
    flash_status_port: 20292

pd_servers:
  - host: 10.0.1.40
  - host: 10.0.1.41
  - host: 10.0.1.42

monitoring_servers:
  - host: 10.0.1.50

grafana_servers:
  - host: 10.0.1.50

部署集群：

# 部署集群
tiup cluster deploy tidb-htap v7.5.0 ./topology.yaml -u root -p

# 启动集群
tiup cluster start tidb-htap

# 检查集群状态
tiup cluster display tidb-htap

列存副本同步配置与查询路由

TiDB通过悲观事务模型保证OLTP一致性。TiFlash副本按表粒度开启，建表时即可指定：

-- 创建表并同步开启TiFlash列存副本
CREATE TABLE orders (
    order_id BIGINT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INT NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    order_status TINYINT,
    created_at DATETIME NOT NULL,
    updated_at DATETIME,
    INDEX idx_user (user_id, created_at),
    INDEX idx_product (product_id, order_status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 添加TiFlash副本（2个副本跨节点冗余）
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- 为已有表添加列存副本
ALTER TABLE order_items SET TIFLASH REPLICA 1;

-- 查看副本同步进度
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_NAME = 'orders';
-- 返回：
-- TABLE_SCHEMA | TABLE_NAME | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS
-- test         | orders     | 2             |                 | 1         | 1.0
-- Available=1表示列存副本就绪可查询

SQL查询优化器根据查询特征自动选择从TiKV（行存）还是TiFlash（列存）读取数据，也可通过Hint强制指定：

-- 强制使用TiFlash列存读取（适合聚合分析查询）
SELECT /*+ read_from_storage(tiflash[orders]) */
    DATE(created_at) AS order_date,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount,
    AVG(amount) AS avg_amount
FROM orders
WHERE created_at >= '2026-07-01'
GROUP BY DATE(created_at)
ORDER BY order_date;

-- 强制使用TiKV行存读取（适合点查询和短范围扫描）
SELECT /*+ read_from_storage(tikv[orders]) */
    *
FROM orders
WHERE order_id = 10086;

-- 查看实际使用的存储引擎
EXPLAIN ANALYZE
SELECT region, SUM(amount)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY region;
-- 执行计划中会显示 cop_tiflash 或 cop_tikv

HTAP场景下的查询性能调优

SQL查询优化在HTAP架构下需要关注存储引擎选择是否合理。查看实际执行计划：

EXPLAIN ANALYZE
SELECT
    o.user_id,
    u.username,
    COUNT(*) AS order_cnt,
    SUM(o.amount) AS total_spent
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.created_at >= '2026-08-01'
  AND o.order_status = 2
GROUP BY o.user_id, u.username
ORDER BY total_spent DESC
LIMIT 20;

-- 执行计划关键节点：
-- TopN_7
-- └─HashAgg_8
--   └─Projection_9
--     └─HashJoin_10
--       ├─Selection_12(读users表, cop_tikv)    ← 行存：点查询效率高
--       └─Selection_13(读orders表, cop_tiflash) ← 列存：聚合扫描效率高

优化要点：

1. 聚合分析查询走TiFlash：SUM/COUNT/AVG/GROUP BY等操作在列存上扫描效率远高于行存，TiFlash按列读取时只加载涉及的列，I/O量大幅减少。

2. 点查询走TiKV：WHERE order_id = ?这类等值查询走行存的B+Tree索引，延迟在1ms以内。

3. 避免索引选择失误：优化器偶发选择全表扫描，可用USE INDEX或FORCE INDEX强制走索引。

数据库高可用架构层面，TiFlash节点的容灾能力依赖Raft Learner的多数派机制。TiFlash节点宕机不影响行存数据的强一致性，只影响分析查询的可用性。推荐至少部署2个TiFlash节点：

-- 设置 Placement Rules 控制TiFlash副本分布
-- 确保两个TiFlash副本分布在不同物理节点
SET @@global.tidb_placement_mode = 'strict';
ALTER TABLE orders
SET TIFLASH REPLICA 2
LOCATION LABELS "host";

数据迁移实战中从MySQL迁移到TiDB HTAP架构，使用TiDB Lightning进行全量导入，再使用DM（Data Migration）做增量同步：

# 使用Lightning全量导入
tiup tidb-lightning \
  -config lightning.toml \
  -tidb-port 4000 \
  -tidb-host 10.0.1.10

# 使用DM增量同步MySQL binlog
tiup dmctl --master-addr 10.0.1.40:8261
> start-task ./mysql_to_tidb.yaml

导入完成后对目标表开启TiFlash副本，OLAP查询自动切换到列存引擎。主从架构下TiDB支持通过CDC（Change Data Capture）将TiKV数据变更实时推送到下游Kafka或MySQL，满足异构数据同步需求。