TiDB分布式数据库架构实战：HTAP行列混合存储与水平扩展方案

TiDB是PingCAP开源的分布式关系型数据库，兼容MySQL协议，支持水平扩展和HTAP（混合事务分析处理）工作负载。传统架构中OLTP和OLAP需要两套数据库系统，通过ETL同步数据，延迟和一致性难以兼顾。TiDB的TiKV+TiFlash行列混合存储架构，在单一数据库中同时满足高并发事务写入和实时分析查询需求。本文从架构原理、部署配置到性能调优，给出TiDB生产环境落地方案。

TiDB整体架构与组件职责

TiDB集群由三个核心组件构成：TiDB Server（SQL层）、TiKV（行存储引擎）和PD（Placement Driver，调度中心）。TiFlash作为可选组件，提供列存储副本用于OLAP加速。

TiDB Server负责SQL解析、执行计划生成和计算，本身无状态，可以任意扩展。TiKV基于RocksDB构建，使用Raft协议保证数据一致性，数据按Region（默认96MB）自动分片。PD负责Region调度和负载均衡，通过心跳收集集群状态。TiFlash以Raft Learner角色从TiKV实时同步数据，实现行列混合存储。

TiDB集群部署与配置

使用TiUP工具部署TiDB集群是官方推荐方式：

# 安装TiUP
curl --proto '=https' --tlsv1.2 -sSf     https://tiup-mirrors.pingcap.com/install.sh | sh
source ~/.bash_profile

# topo.yaml 集群拓扑配置
global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/tidb-deploy"
  data_dir: "/tidb-data"

tidb_servers:
  - host: 10.0.1.1
  - host: 10.0.1.2
  - host: 10.0.1.3

tikv_servers:
  - host: 10.0.2.1
    config:
      storage.block-cache.capacity: "8GB"
  - host: 10.0.2.2
    config:
      storage.block-cache.capacity: "8GB"
  - host: 10.0.2.3
    config:
      storage.block-cache.capacity: "8GB"

pd_servers:
  - host: 10.0.3.1
  - host: 10.0.3.2
  - host: 10.0.3.3

tiflash_servers:
  - host: 10.0.4.1
    config:
      storage.main.capacity: "1TB"
  - host: 10.0.4.2
    config:
      storage.main.capacity: "1TB"

# 部署集群
tiup cluster deploy tidb-prod v7.5.0 ./topo.yaml -u root -p
# 启动集群
tiup cluster start tidb-prod
# 查看集群状态
tiup cluster display tidb-prod

HTAP行列混合查询实战

TiFlash副本创建后，TiDB优化器会自动判断查询类型，OLTP走TiKV行存储，OLAP走TiFlash列存储。通过SQL Hint可以强制指定查询路径：

-- 创建TiFlash副本
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- 查看同步进度
SELECT * FROM information_schema.tiflash_replica
WHERE table_schema = 'ecommerce' AND table_name = 'orders';

-- 自动路由：分析查询走TiFlash
SELECT region, COUNT(*) AS order_count, SUM(amount) AS total
FROM orders
WHERE create_time >= '2026-01-01'
GROUP BY region
ORDER BY total DESC
LIMIT 20;

-- 强制走TiFlash
SELECT /*+ read_from_storage(tiflash[orders]) */
    region, COUNT(*) AS cnt, SUM(amount) AS total
FROM orders
GROUP BY region;

-- 强制走TiKV（OLTP点查）
SELECT /*+ read_from_storage(tikv[orders]) */
    id, order_no, amount, status
FROM orders
WHERE id = 12345678;

水平扩展与Region分裂调优

-- 设置Region大小
SET CONFIG tikv coprocessor.region-max-size: '128MB';
SET CONFIG tikv coprocessor.region-split-size: '96MB';

-- PD调度配置
SET config pd schedule.region-schedule-limit: 4;
SET config pd schedule.store-balance-rate: 8;

-- 识别热点Region
SELECT * FROM information_schema.tidb_hot_regions
WHERE table_name = 'orders'
ORDER BY flow_bytes DESC LIMIT 10;

-- 手动分裂热点Region
SPLIT TABLE orders BETWEEN (0) AND (100000000) REGIONS 16;

SQL执行计划分析与索引优化

-- 查看执行计划
EXPLAIN ANALYZE
SELECT o.order_no, o.amount, c.customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.create_time >= '2026-09-01'
  AND o.status = 'paid'
ORDER BY o.amount DESC
LIMIT 50;

-- 复合索引：等值条件在前，范围条件在后
ALTER TABLE orders ADD INDEX idx_status_create_time (status, create_time);

-- 覆盖索引避免回表
ALTER TABLE orders ADD INDEX idx_covering (status, create_time, amount, order_no);

-- 统计信息更新
ANALYZE TABLE orders WITH 256 BUCKETS;

-- 强制使用指定索引
SELECT /*+ use_index(orders, idx_status_create_time) */
    order_no, amount
FROM orders
WHERE status = 'paid' AND create_time >= '2026-09-01';

备份恢复与数据迁移

# 全量备份到S3
tiup br backup full     --pd "10.0.3.1:2379"     --storage "s3://tidb-backup/full-20260904"     --ratelimit 128 --concurrency 4

# 恢复
tiup br restore full     --pd "10.0.3.1:2379"     --storage "s3://tidb-backup/full-20260904"

# 从MySQL迁移数据
tiup dumpling     --host 10.0.10.1 --port 3306 --user root     --output ./mysql-export/ --threads 8

tiup tidb-lightning     --tidb-port 4000 --tidb-host 10.0.1.1     --backend tidb --sorted-kv-dir ./sorted-kv/

TiDB在兼容MySQL协议的同时解决了单机数据库的水平扩展瓶颈。HTAP架构通过TiFlash列存储副本，避免了OLTP到OLAP的数据搜运延迟。对于数据量超过单机MySQL承载能力（通常500GB以上）且存在实时分析需求的业务场景，TiDB是值得考虑的选型。部署时需注意TiKV节点配置SSD存储，PD节点建议3个以上保证调度可用性，TiFlash节点内存不低于64GB以提升列存查询性能。