分布式数据库 TiDB 调优与实战指南

数据库

为什么 2026 年选择 TiDB？

TiDB 作为新一代 HTAP（Hybrid Transactional and Analytical Processing） 分布式数据库，在 2026 年已成为企业级数据库升级的首选方案。它完美解决了传统 MySQL 单机瓶颈和分库分表复杂度问题。

TiDB 核心优势

维度 TiDB MySQL 分库分表 CockroachDB Amazon Aurora
扩展方式 透明水平扩展 应用层分片 水平扩展 垂直+读扩展
MySQL 兼容 极高（95%+） 原生 MySQL 中等 高
HTAP 能力 原生支持 需额外组件 不支持 有限
运维复杂度 中等（TiUP） 高 中等 低（托管）
强一致性 Raft 协议 原生 Raft 协议 有限
开源 完全开源 - 开源 闭源

2026 年 TiDB 的关键进展

  1. TiDB 8.x 稳定版：性能提升 40%+，支持更大数据量级
  2. TiFlash MPP 增强：实时分析能力大幅提升，支持更多窗口函数
  3. Serverless TiDB：云原生按需付费模式，降低使用门槛
  4. 资源管控（Resource Control）：多租户场景下的 CPU/IO 隔离
  5. Global Sort：大幅降低大规模数据导入的开销

TiDB 架构全景解析

TiDB 采用计算存储分离架构，由四个核心组件构成：

组件职责

┌─────────────────────────────────────────────────────┐
│                    Client (MySQL Protocol)           │
└──────────────┬──────────────────────────────────────┘
               │
┌──────────────▼──────────────────────────────────────┐
│              TiDB Server (SQL 层)                    │
│  ┌─────────┐ ┌──────────┐ ┌───────────────┐        │
│  │ Parser  │ │ Optimizer│ │ Executor      │        │
│  └─────────┘ └──────────┘ └───────────────┘        │
└──────────────┬──────────────────────────────────────┘
               │
┌──────────────▼──────────────────────────────────────┐
│           PD (Placement Driver)                      │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐        │
│  │ 调度器   │ │ 元信息   │ │ TSO 时钟     │        │
│  └──────────┘ └──────────┘ └──────────────┘        │
└──────────────┬──────────────────────────────────────┘
               │
┌──────────────▼──────────────────────────────────────┐
│    TiKV (行存)              TiFlash (列存)           │
│  ┌─────────┐               ┌──────────────┐        │
│  │ Raft    │               │ DeltaTree    │        │
│  │ RocksDB │               │ ClickHouse   │        │
│  └─────────┘               └──────────────┘        │
└─────────────────────────────────────────────────────┘
  • TiDB Server：无状态 SQL 计算层，负责 SQL 解析、优化和执行
  • PD（Placement Driver）：集群大脑，负责调度、元信息管理和全局时间戳
  • TiKV：行存储引擎，基于 RocksDB + Raft，承载事务读写
  • TiFlash：列存储引擎，基于 ClickHouse 技术，承载实时分析

数据流转机制

  1. 写入路径：Client → TiDB → PD（获取 TSO）→ TiKV（Raft 写入）→ TiFlash（异步同步）
  2. 读取路径（OLTP）：Client → TiDB → TiKV（点查/范围查）
  3. 读取路径（OLAP）：Client → TiDB → TiFlash（MPP 并行计算）

💡 使用 SQL 格式化 工具美化 TiDB 的 SQL 查询语句，便于分析执行计划。

使用 TiUP 部署 TiDB 集群

TiUP 是 TiDB 官方的集群管理工具，支持一键部署、扩缩容和升级。

环境准备

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

# 验证安装
tiup --version

单机测试集群部署

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

monitored:
  node_exporter_port: 9100
  blackbox_exporter_port: 9115

server_configs:
  tidb:
    log.level: "info"
    performance.max-procs: 4
  tikv:
    readpool.coprocessor.max-concurrency: 8
    raftstore.apply-pool-size: 3
    raftstore.store-pool-size: 3
  pd:
    schedule.max-merge-region-size: 20

pd_servers:
  - host: 10.0.1.1

tidb_servers:
  - host: 10.0.1.1

tikv_servers:
  - host: 10.0.1.1

tiflash_servers:
  - host: 10.0.1.1

monitoring_servers:
  - host: 10.0.1.1

grafana_servers:
  - host: 10.0.1.1

# 部署集群
tiup cluster deploy tidb-prod v8.5.1 topo.yaml

# 启动集群
tiup cluster start tidb-prod

# 查看集群状态
tiup cluster display tidb-prod

# 连接 TiDB
mysql -h 10.0.1.1 -P 4000 -u root

生产环境部署要点

  1. PD 部署 3 个节点：保证调度器高可用
  2. TiKV 部署至少 3 个节点：Raft 多数派写入
  3. TiDB 部署 2+ 节点：前端负载均衡
  4. TiFlash 独立部署：避免与 TiKV 争抢 I/O
  5. SSD 磁盘：TiKV 数据目录必须使用 NVMe SSD
  6. 网络：节点间延迟 < 0.5ms，带宽 ≥ 10Gbps

MySQL 兼容性清单

TiDB 高度兼容 MySQL 5.7 / 8.0 协议，但存在部分差异需要注意：

兼容特性

特性 支持情况 备注
SELECT / INSERT / UPDATE / DELETE ✅ 完全支持
JOIN（所有类型） ✅ 完全支持
子查询 ✅ 完全支持
窗口函数 ✅ 完全支持 TiDB 6.0+
CTE（公用表表达式） ✅ 完全支持 TiDB 6.0+
Prepared Statement ✅ 完全支持
JSON 类型 ✅ 完全支持
UTF8 / UTF8MB4 ✅ 完全支持

不兼容特性

特性 状态 替代方案
存储过程 ❌ 不支持 使用应用层逻辑
触发器 ❌ 不支持 使用应用层事件
外键约束 ⚠️ 语法支持但不强制 应用层保证一致性
XA 语法 ⚠️ 部分支持 使用 TiDB 内部 2PC
自增 ID 连续性 ⚠️ 不保证连续 使用 AUTO_ID_CACHE 或序列
SAVEPOINT ✅ 支持 TiDB 6.2+
SELECT ... FOR UPDATE 锁 ⚠️ 悲观锁支持 需显式开启悲观事务

兼容性验证脚本

-- 检查 TiDB 版本与兼容性
SELECT tidb_version();

-- 查看当前事务模式
SELECT @@tidb_txn_mode;

-- 检查自增 ID 行为
SHOW VARIABLES LIKE 'auto_increment%';

-- 查看字符集支持
SHOW CHARACTER SET WHERE Charset LIKE '%utf%';

💡 使用 JSON 格式化 工具验证 TiDB 返回的 JSON 数据结构。

SQL 优化与执行计划分析

EXPLAIN 与 EXPLAIN ANALYZE

TiDB 提供了丰富的执行计划分析工具：

-- 查看执行计划
EXPLAIN SELECT o.order_id, c.customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE o.order_date >= '2026-01-01'
  AND o.status = 'shipped';

-- 查看实际执行统计（含时间、行数）
EXPLAIN ANALYZE SELECT o.order_id, c.customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE o.order_date >= '2026-01-01'
  AND o.status = 'shipped';

执行计划关键算子

算子 含义 优化方向
TableFullScan 全表扫描 添加合适索引
IndexRangeScan 索引范围扫描 已较优，检查回表代价
IndexLookUp 索引回表 考虑覆盖索引
IndexReader 索引读取（无需回表） 覆盖索引，最优
HashJoin 哈希连接 检查 Build 侧数据量
MergeJoin 归并连接 确保两侧有序
IndexJoin 索引嵌套连接 适合小表驱动大表
StreamAgg 流式聚合 已较优
HashAgg 哈希聚合 检查分组基数
TopN TopN 排序 已较优
Sort 全排序 检查是否可利用索引序

SQL 调优实战案例

-- 案例 1：避免全表扫描
-- 问题：status 选择性低，导致全表扫描
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
-- 优化：添加复合索引
ALTER TABLE orders ADD INDEX idx_status_date (status, order_date);

-- 案例 2：覆盖索引消除回表
-- 问题：IndexLookUp 回表代价高
EXPLAIN SELECT customer_id, order_date FROM orders WHERE status = 'shipped';
-- 优化：覆盖索引
ALTER TABLE orders ADD INDEX idx_cover (status, customer_id, order_date);

-- 案例 3：优化 JOIN 顺序
-- 问题：HashJoin Build 侧数据量过大
EXPLAIN ANALYZE SELECT *
FROM order_items oi
JOIN products p ON oi.product_id = p.product_id
WHERE p.category = 'electronics';
-- 优化：添加驱动表索引 + 统计信息更新
ANALYZE TABLE products;
ANALYZE TABLE order_items;

绑定执行计划（SPM）

-- 创建 SQL Binding 绑定最优执行计划
CREATE SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped'
USING
  SELECT * FROM orders USE INDEX (idx_status_date) WHERE status = 'shipped';

-- 查看已有 Binding
SHOW SESSION BINDINGS;

-- 删除 Binding
DROP SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped';

分布式索引策略

分布式数据库的索引设计与单机 MySQL 有显著差异，需考虑跨 Region 代价和热点风险。

索引设计原则

  1. 减少 Region 扫描：索引前缀应尽量分散，避免集中在少量 Region
  2. 控制索引数量：每个索引都会增加写入开销和存储空间
  3. 优先复合索引：减少回表次数，一个复合索引替代多个单列索引
  4. 避免过宽索引：索引列总宽度建议 < 200 字节
  5. 注意索引放置：TiDB 支持索引放置到不同存储引擎

索引放置策略（Placement Rules）

-- 将冷数据索引放置到 HDD 存储
ALTER TABLE orders ADD INDEX idx_create_time (create_time)
  PLACEMENT POLICY 'cold_storage';

-- 创建放置策略
CREATE PLACEMENT POLICY cold_storage LEADER_CONSTRAINTS '[+disk=hdd]' FOLLOWER_CONSTRAINTS '[+disk=hdd]';

不可见索引

-- 创建不可见索引（不影响查询，仅写入维护）
ALTER TABLE orders ADD INDEX idx_test (customer_id) INVISIBLE;

-- 验证索引不可见
SHOW INDEXES FROM orders;

-- 确认无性能影响后设为可见
ALTER TABLE orders ALTER INDEX idx_test VISIBLE;

热点问题排查与解决

热点是分布式数据库最常见的问题，会导致部分节点负载过高。

热点识别

-- 查看热点 Region 分布
SELECT STORE_ID, COUNT(*) AS region_count
FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS
GROUP BY STORE_ID
ORDER BY region_count DESC;

-- 查看写入热点
SELECT TABLE_NAME, INDEX_NAME, WRITTEN_BYTES, READ_BYTES
FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS
WHERE WRITTEN_BYTES > 1048576
ORDER BY WRITTEN_BYTES DESC
LIMIT 20;

常见热点场景与解决方案

场景 1：自增 ID 热点

-- 问题：AUTO_INCREMENT 导致写入集中在单个 Region
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  content TEXT,
  created_at TIMESTAMP
);

-- 解决方案 1：使用 SHARD_ROW_ID_BITS 打散
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  created_at TIMESTAMP,
  PRIMARY KEY (id)
) SHARD_ROW_ID_BITS = 4;

-- 解决方案 2：使用时间戳作为主键前缀
CREATE TABLE logs (
  created_at TIMESTAMP,
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  PRIMARY KEY (created_at, id)
) SHARD_ROW_ID_BITS = 4;

场景 2：索引热点

-- 问题：时间索引写入集中在尾部 Region
ALTER TABLE orders ADD INDEX idx_created (created_at);

-- 解决方案：使用 SHARD_ROW_ID_BITS + PRE_SPLIT_REGIONS
CREATE TABLE orders (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  order_no VARCHAR(64),
  created_at TIMESTAMP,
  amount DECIMAL(10,2)
) SHARD_ROW_ID_BITS = 4
  PRE_SPLIT_REGIONS = 4;

场景 3：小表全量热点

-- 问题：小表数据集中在单个 Region，高并发读取热点
-- 解决方案：使用 Follower Read 分担读压力
SET @@tidb_replica_read = 'leader-and-follower';

-- 或在会话级别开启
SET SESSION tidb_replica_read = 'follower';

PD 调度优化

# 查看当前调度配置
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config show all

# 调整热点调度参数
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config set hot-region-schedule-limit 8
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config set balance-hot-region-schedule-limit 4

# 开启 Region Merge 减少空 Region
tiup ctl:v8.5.1 pd -u http://10.0.0.1:2379 config set enable-merge-region true

TiFlash 实时分析实战

TiFlash 是 TiDB 的列存引擎，无需 ETL 即可实现实时 OLAP 分析。

启用 TiFlash 同步

-- 对整库启用 TiFlash 同步
ALTER DATABASE orders_db SET TIFLASH REPLICA 2;

-- 对单表启用 TiFlash 同步（2 副本）
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- 查看同步进度
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- 指定列同步到 TiFlash（减少同步开销）
ALTER TABLE orders SET TIFLASH REPLICA 1
  INCLUDE (order_id, customer_id, amount, order_date);

MPP 模式查询

-- 强制使用 TiFlash MPP 引擎
SET @@tidb_isolation_read_engines = 'tiflash';
SET @@tidb_enforce_mpp = 1;

-- 实时销售分析
SELECT
  DATE(order_date) AS dt,
  p.category,
  COUNT(*) AS order_count,
  SUM(oi.quantity * oi.unit_price) AS revenue,
  AVG(oi.quantity * oi.unit_price) AS avg_order_value
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE o.order_date >= '2026-01-01'
GROUP BY DATE(order_date), p.category
ORDER BY dt DESC, revenue DESC;

-- 恢复默认引擎选择
SET @@tidb_isolation_read_engines = 'tidb,tikv,tiflash';
SET @@tidb_enforce_mpp = 0;

HTAP 智能路由

-- TiDB 自动路由：小查询走 TiKV，大查询走 TiFlash
-- 无需手动设置，优化器自动判断

-- 查看查询实际使用的引擎
EXPLAIN ANALYZE SELECT COUNT(*), SUM(amount)
FROM orders WHERE order_date >= '2026-01-01';
-- 观察 operator 中是否包含 tiflash 相关信息

备份与容灾恢复（BR）

BR（Backup & Restore）是 TiDB 原生的分布式备份恢复工具。

全量备份与恢复

# 全量备份到 S3
tiup br:v8.5.1 backup full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/full-20260611" \
  --s3.region "us-east-1" \
  --send-credentials-to-tikv true \
  --concurrency 4

# 全量恢复
tiup br:v8.5.1 restore full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/full-20260611" \
  --s3.region "us-east-1"

增量备份

# 增量备份（基于上次备份的 TS）
tiup br:v8.5.1 backup full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/incr-20260611" \
  --last-backup-ts 450335849738604544

单库/单表备份

# 单库备份
tiup br:v8.5.1 backup db \
  --db "orders_db" \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/orders-db-20260611"

# 单表备份
tiup br:v8.5.1 backup table \
  --db "orders_db" \
  --table "orders" \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/orders-table-20260611"

基于时间点的恢复（PITR）

# 恢复到指定时间点
tiup br:v8.5.1 restore full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/full-20260611" \
  --restored-ts "2026-06-11T14:30:00+08:00"

💡 使用 哈希加密 工具验证备份数据的完整性校验和。

Grafana 监控体系

TiDB 集群自带完整的 Prometheus + Grafana 监控体系。

核心监控面板

面板 关键指标 告警阈值建议
TiDB Overview QPS、连接数、慢查询 慢查询 > 1s
TiKV Details CPU、IO、Region 数 CPU > 80%
PD Details 调度任务、Region 分布 调度延迟 > 5min
TiFlash Details 同步延迟、MPP 任务数 同步延迟 > 10s
BR 备份进度、耗时 备份失败
Node Exporter 磁盘、内存、网络 磁盘使用 > 85%

关键指标详解

# TiDB 关键指标
tidb_server_query_duration:
  description: "查询延迟 P99"
  alert: "> 500ms 持续 5 分钟"

tidb_server_slow_query:
  description: "慢查询数量"
  alert: "> 10/min"

tikv_grpc_message_duration:
  description: "TiKV gRPC 请求延迟"
  alert: "P99 > 200ms"

tikv_engine_write_bytes:
  description: "写入吞吐量"
  monitoring: "关注突降"

pd_scheduler_balance_region:
  description: "Region 调度速度"
  alert: "持续为 0 超过 10 分钟"

tiflash_sync_apply_duration:
  description: "TiFlash 数据同步延迟"
  alert: "P99 > 10s"

自定义告警规则

# Prometheus 告警规则示例
groups:
  - name: tidb_alerts
    rules:
      - alert: TiDBHighQPS
        expr: sum(rate(tidb_server_handle_query_duration_seconds_count[1m])) > 50000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "TiDB QPS 过高"
          description: "当前 QPS 超过 50000，持续 5 分钟"

      - alert: TiKVHighWriteLag
        expr: histogram_quantile(0.99, rate(tikv_grpc_message_duration_seconds_bucket{type="write"}[5m])) > 0.5
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "TiKV 写入延迟过高"
          description: "P99 写入延迟超过 500ms"

常见错误与排查

错误 1：Region 读写超时

Error: region is unavailable, wait for a while and retry

排查步骤：

# 1. 检查 Region 状态
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 region check miss-peer

# 2. 检查 TiKV 健康状态
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 store

# 3. 查看慢日志
tiup cluster audit tidb-prod --limit 50

错误 2：写入冲突（Write Conflict）

Error: Write conflict, txn start_ts conflicts with another txn

解决方案：

-- 调整事务重试参数
SET @@tidb_retry_limit = 20;
SET @@tidb_txn_retry_interval = 100; -- 毫秒

-- 检查冲突率
SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX
  WHERE state = 'LockRcolliding' LIMIT 10;

错误 3：OOM（内存不足）

Error: Out Of Memory Quota!

解决方案：

-- 设置查询内存限制
SET @@tidb_mem_quota_query = 1073741824; -- 1GB

-- 开启资源管控
CREATE RESOURCE GROUP rg_report
  RU_PER_SEC = 500
  PRIORITY = LOW;

-- 将用户绑定到资源组
ALTER USER report_user RESOURCE GROUP rg_report;

错误 4：TiFlash 同步延迟

-- 检查同步进度
SELECT TABLE_ID, REPLICA_COUNT, PROGRESS, AVAILABLE
FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- 检查 TiFlash 节点状态
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_TABLES
  WHERE REPLICA_AVAILABLE = 0;

从 MySQL 迁移到 TiDB

迁移方案对比

方案 适用场景 停机时间 复杂度
DM 全量+增量 大规模迁移 近零 中
Dumpling + TiDB Lightning 一次性迁移 数小时 低
mysqldump + source 小数据量 数小时 低

使用 DM 迁移（推荐）

# dm-task.yaml - DM 迁移任务配置
name: mysql-to-tidb
task-mode: all
target-database:
  host: "10.0.2.1"
  port: 4000
  user: "root"
  password: ""

mysql-instances:
  - source-id: "mysql-replica-01"
    block-allow-list: "bw-rule-1"

block-allow-list:
  bw-rule-1:
    do-dbs: ["orders_db", "users_db"]
    ignore-tables:
      - db-name: "orders_db"
        tbl-name: "log_*"

# 启动 DM 任务
dmctl start-task dm-task.yaml

# 查看任务状态
dmctl query-status mysql-to-tidb

# 校验数据一致性
dmctl check-task dm-task.yaml

迁移前兼容性检查

-- 检查存储过程使用情况
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys');

-- 检查外键约束
SELECT TABLE_SCHEMA, TABLE_NAME, CONSTRAINT_NAME
FROM information_schema.table_constraints
WHERE CONSTRAINT_TYPE = 'FOREIGN KEY';

-- 检查触发器
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE
FROM information_schema.triggers;

-- 检查自增列使用
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, AUTO_INCREMENT
FROM information_schema.columns
WHERE EXTRA LIKE '%auto_increment%';

性能基准测试

TPCC 基准测试

# 使用 TPCC 测试 OLTP 性能
git clone https://github.com/pingcap/go-tpc.git
cd go-tpc

# 准备数据
go-tpc tpcc prepare \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50

# 运行测试
go-tpc tpcc run \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50 \
  --time 600s

# 清理数据
go-tpc tpcc cleanup \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000

TPC-H 基准测试（HTAP）

# TPC-H 测试 OLAP 性能
go-tpc tpch prepare \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10

# 强制 TiFlash 执行
go-tpc tpch run \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10 \
  --time 300s \
  --engine tiflash

典型性能参考

场景 节点配置 QPS/TPS 延迟 P99
OLTP（TPCC） 3×TiDB + 3×TiKV 15,000 TPS < 50ms
OLAP（TPC-H） + 2×TiFlash 22 条/5min 各查询差异大
混合 HTAP 上述配置 TP 不降 + AP 10x 各自独立

常见问题 FAQ

Q1：TiDB 适合替代 MySQL 分库分表吗？

是的，这是 TiDB 最典型的使用场景。TiDB 提供透明水平扩展，无需应用层分片逻辑，且保持 MySQL 协议兼容，迁移成本极低。当单表数据超过 5000 万行或分库分表运维复杂度过高时，强烈建议迁移到 TiDB。

Q2：TiDB 的事务隔离级别是什么？

TiDB 默认使用 RC（Read Committed） 隔离级别（v6.0+），也支持 RR（Repeatable Read） 语义。TiDB 的 RR 实际上是 Snapshot Isolation（SI），不会出现幻读，但与 MySQL 的 RR 在特定场景下有细微差异（如当前读行为）。

Q3：TiDB 的最佳实践数据量级？

  • 单表：千万到百亿行均可，建议单表超过 5000 万行时使用 TiDB
  • 集群总数据量：TB 到 PB 级别
  • Region 大小：默认 96MB，建议保持在此值附近

Q4：TiDB 和 CockroachDB 如何选择？

维度 TiDB CockroachDB
MySQL 兼容 极高 PostgreSQL 兼容
HTAP 原生支持 不支持
社区 中国/亚太为主 全球
云服务 TiDB Cloud CockroachDB Cloud

如果现有技术栈基于 MySQL 且需要 HTAP，选 TiDB；如果基于 PostgreSQL 且只需 OLTP，选 CockroachDB。

Q5：如何处理 TiDB 中的大事务？

TiDB 默认事务限制为 100MB 和 5000 行。大事务处理方案：

-- 调整事务限制（不推荐过大）
SET @@tidb_txn_entry_size_limit = 536870912;  -- 512MB
SET @@tidb_txn_total_size_limit = 1073741824; -- 1GB

-- 推荐方案：分批提交
-- 应用层将大事务拆分为多个小事务，每批 1000-5000 行

Q6：TiDB 的 License 是什么？

TiDB Server、TiKV、PD 采用 Apache 2.0 完全开源。TiFlash 在 v8.0+ 也已开源。TiDB Cloud（Serverless/Dedicated）为商业服务。

总结

TiDB 在 2026 年已经成为分布式数据库领域的标杆产品，其 MySQL 兼容性、HTAP 能力和云原生架构使其成为企业数据库升级的理想选择。关键要点回顾：

  1. 架构理解：TiDB/TiKV/PD/TiFlash 四组件协同，计算存储分离
  2. 部署运维：TiUP 一键管理，生产环境注意 SSD 和网络要求
  3. SQL 调优：善用 EXPLAIN ANALYZE，掌握 SPM 绑定执行计划
  4. 索引设计：考虑分布式特性，避免热点索引
  5. 热点治理：SHARD_ROW_ID_BITS 打散、Follower Read 分担
  6. HTAP 实战：TiFlash 列存 + MPP 引擎实现实时分析
  7. 容灾备份：BR 工具支持全量/增量/PITR 多种恢复策略
  8. 监控告警：Grafana 体系完善，关键指标不可忽视
  9. 迁移方案：DM 增量迁移实现近零停机切换

本站提供浏览器本地工具，免注册即可试用 →

#TiDB#分布式数据库#NewSQL#MySQL兼容#教程