分散式資料庫 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兼容#教程