TiDB分布式数据库实战：HTAP混合负载与在线扩缩容架构解析

TiDB是PingCAP开源的分布式关系型数据库，兼容MySQL协议，采用计算存储分离架构，支持水平扩展和HTAP（Hybrid Transactional/Analytical Processing）混合负载。TiDB通过TiKV行存引擎处理OLTP事务，通过TiFlash列存引擎处理OLAP分析查询，两个引擎共享同一份数据底座，实现事务与分析的实时一致性。在千亿级数据规模下，TiDB的在线扩缩容能力可在不停止服务的情况下完成节点增减。

TiDB架构概览：计算层与存储层的分离设计

TiDB架构由三个核心组件构成：TiDB Server（计算层）、TiKV（行存储层）和TiFlash（列存储层），PD（Placement Driver）作为全局调度器协调集群。

TiDB架构组件：
TiDB Server (计算层)
├── SQL解析与优化
├── 分布式事务协调
├── 无状态，可水平扩展
└── 兼容MySQL协议

TiKV (行存储层 - OLTP)
├── RocksDB LSM-Tree存储引擎
├── Raft共识协议保证强一致性
├── Region数据分片（默认96MB）
├── Multi-Raft管理副本
└── MVCC多版本并发控制

TiFlash (列存储层 - OLAP)
├── DeltaTree列式存储引擎
├── 强一致性副本（通过Raft Learner同步）
├── 向量化执行引擎
└── 实时分析查询加速

PD (Placement Driver - 调度器)
├── Region元数据管理
├── 副本调度与均衡
├── 事务ID分配（TSO）
└── 集群拓扑感知

TiDB Server是无状态计算节点，不存储数据，可随时增减。SQL请求经过解析、优化生成物理执行计划后，下推到TiKV或TiFlash执行。TiKV以Region为单位存储数据，每个Region是一段连续的Key-Value数据，默认96MB。Region通过Raft协议保证多副本一致性，默认3副本。PD负责Region的分裂、迁移和副本均衡调度。

HTAP混合负载实现：行存与列存的数据同步机制

TiDB的HTAP能力依赖TiFlash实现。TiFlash作为TiKV的列存副本，通过Raft Learner协议实时同步TiKV的数据变更，保证行存和列存数据的强一致性：

-- 创建TiFlash副本（为表添加列存副本）
ALTER TABLE orders SET TIFLASH REPLICA 2;
-- 2表示TiFlash副本数，通常在1-2之间

-- 查看副本同步进度
SELECT * FROM information_schema.tiflash_replica
WHERE table_schema = 'ecommerce' AND table_name = 'orders';
-- AVAILABLE字段为1表示同步完成

-- HTAP查询路由：TiDB Server自动选择执行引擎
-- OLTP查询走TiKV（点查、小范围扫描）
SELECT * FROM orders WHERE order_id = 10086;

-- OLAP查询走TiFlash（大范围聚合分析）
SELECT
    region,
    COUNT(*) AS order_count,
    SUM(amount) AS total_revenue,
    AVG(amount) AS avg_revenue
FROM orders
WHERE order_date >= '2026-01-01'
GROUP BY region
ORDER BY total_revenue DESC;

-- 强制指定执行引擎（调试用）
-- 使用Hint强制走TiFlash
SELECT /*+ read_from_storage(tiflash[orders]) */
    region, SUM(amount)
FROM orders
GROUP BY region;

-- 使用Hint强制走TiKV
SELECT /*+ read_from_storage(tikv[orders]) */
    *
FROM orders
WHERE order_id = 10086;

TiDB优化器基于统计信息和查询特征自动选择TiKV或TiFlash作为执行引擎：等值查询和小范围扫描路由到TiKV（行存点查高效），大范围聚合和分析查询路由到TiFlash（列存向量化扫描高效）。同一张表同时存在行存和列存副本，用户无需感知底层存储差异。TiFlash的强一致性保证通过Raft Learner实现：TiFlash副本作为Raft组中的Learner角色，接收所有写入但不参与Leader选举和投票，读取时通过检查Raft Log Index确保读取到最新已提交数据。

在线水平扩缩容：Region分裂与调度策略

TiDB的在线扩缩容是其分布式架构的核心优势。新增TiKV节点后，PD自动将部分Region迁移到新节点，整个过程不中断服务：

-- 1. 扩容TiKV节点（使用tiup cluster工具）
tiup cluster scale-out tidb-prod scale-tikv.yaml
-- scale-tikv.yaml中定义新节点的IP和端口

-- 2. 查看集群状态和Region分布
SHOW TABLE regions;

-- 使用PD API查看详细调度状态
curl http://pd-host:2379/pd/api/v1/cluster
-- 返回Region数量、副本分布、Leader分布

curl http://pd-host:2379/pd/api/v1/stores
-- 返回各Store的Region数、容量、可用空间

-- 3. Region迁移是自动的，PD调度策略可配置
curl -X POST http://pd-host:2379/pd/api/v1/config -d '{
  "schedule": {
    "max-merge-region-size": 20,
    "max-merge-region-keys": 200000,
    "split-merge-interval": "1h",
    "max-snapshot-count": 3,
    "balance-region-interval": "10s",
    "balance-leader-interval": "10s"
  }
}'

-- 4. 缩容节点（安全移除）
tiup cluster scale-in tidb-prod --node 192.168.1.20:20160
-- PD会将该节点上的Region迁移到其他节点后安全下线

Region迁移过程的细节：PD选择迁移的Region为新节点上Region数最少的Store，先在目标节点创建Raft Learner副本，等待Learner追平数据后提升为Follower，再移除源节点的旧副本。整个迁移过程Region可用性不受影响，Raft多数派始终满足。扩容时建议分批添加节点（每次2-3个），避免大量Region同时迁移影响在线性能。

TiDB SQL执行流程与统计信息收集

TiDB的SQL优化器基于Cascades框架实现，执行计划生成过程包括逻辑优化（规则改写）和物理优化（代价估算）。统计信息准确性直接影响执行计划质量：

-- 查看执行计划
EXPLAIN ANALYZE
SELECT o.order_id, c.customer_name, o.amount
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE o.order_date >= '2026-09-01'
  AND c.region = '华东'
ORDER BY o.amount DESC
LIMIT 100;

-- 执行计划输出示例
-- +------------------------------+----------+---------+-----------+
-- | id                           | estRows  | actRows | task      |
-- +------------------------------+----------+---------+-----------+
-- | TopN_7                       | 100.00   | 100     | root      |
-- | └─HashJoin_11               | 1250.00  | 980     | root      |
-- |   ├─TableReader_16(Build)    | 5000.00  | 4920    | root      |
-- |   │ └─Selection_15          | 5000.00  | 4920    | cop[tikv] |
-- |   │   └─TableRangeScan_14   | 10000.0  | 10000   | cop[tikv] |
-- |   └─TableReader_19(Probe)    | 1250.00  | 980     | root      |
-- |     └─Selection_18          | 1250.00  | 980     | cop[tikv] |
-- |       └─TableRangeScan_17   | 10000.0  | 10000   | cop[tikv] |
-- +------------------------------+----------+---------+-----------+

-- 统计信息收集
ANALYZE TABLE orders WITH 256 BUCKETS;
-- 手动收集统计信息，指定直方图桶数

-- 查看统计信息状态
SHOW STATS_META WHERE table_name = 'orders';
-- 返回行数、修改次数等元信息

-- 自动统计信息收集配置
SET GLOBAL tidb_auto_analyze_ratio = 0.2;
-- 当修改行数超过总行数20%时触发自动收集

SET GLOBAL tidb_auto_analyze_start_time = '00:00';
SET GLOBAL tidb_auto_analyze_end_time = '06:00';
-- 限制自动收集在凌晨执行

TiDB与MySQL兼容性及迁移方案

TiDB兼容MySQL 5.7协议和大部分语法，但存在部分不兼容特性。迁移前需评估兼容性差异：

-- TiDB不支持但MySQL支持的功能：
-- 1. 外键约束（TiDB解析但不强制执行）
-- 2. 存储过程和触发器（TiDB不支持）
-- 3. 自增ID在分布式环境下非连续

-- TiDB迁移工具：DM (Data Migration)
# DM配置文件 dm-task.yaml
name: mysql-to-tidb
task-mode: all  # 全量+增量

mysql-instances:
  - source-id: mysql-source-1
    block-allow-list: ba-list0

block-allow-list:
  ba-list0:
    do-dbs: ["ecommerce", "analytics"]
    ignore-tables:
      - db-name: "ecommerce"
        tbl-name: "~^tmp_.*"

# 启动DM同步任务
tiup dmctl start-task mysql-to-tidb

# 查看同步状态
tiup dmctl query-status mysql-to-tidb

-- TiDB特有的优化特性
-- 1. 在线DDL（不锁表）
ALTER TABLE orders ADD COLUMN remark VARCHAR(500);

-- 2. 全局序列号（取代自增ID）
CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_RANDOM(5),
    order_no VARCHAR(32) UNIQUE,
    amount DECIMAL(10,2)
);

-- 3. 分区表
CREATE TABLE logs (
    id BIGINT,
    log_time DATETIME,
    content TEXT
) PARTITION BY RANGE (TO_DAYS(log_time)) (
    PARTITION p202601 VALUES LESS THAN (TO_DAYS('2026-02-01')),
    PARTITION p202602 VALUES LESS THAN (TO_DAYS('2026-03-01')),
    PARTITION p202603 VALUES LESS THAN (TO_DAYS('2026-04-01')),
    PARTITION pmax VALUES LESS THAN MAXVALUE
);

从MySQL迁移到TiDB的主要收益：摆脱单机存储容量限制（TiKV可线性扩展到PB级）、消除分库分表中间件复杂度（TiDB原生分布式SQL）、HTAP混合负载无需ETL数据搬运。迁移风险点包括：分布式事务延迟高于单机MySQL（跨Region事务延迟增加5-15ms）、部分MySQL存储过程需重构为应用层逻辑、TiDB对高并发小事务的QPS上限低于单机MySQL。适合迁移的场景是数据量超过单机MySQL承载能力（通常500GB以上）、需要实时分析能力、或需要在线扩缩容能力的业务系统。