一、概述

1.1 背景介紹

TiDB 是 PingCAP 開發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫，兼容 MySQL 5.7 協(xié)議，底層存儲基于 TiKV（分布式 KV 存儲）和 RocksDB。它解決的核心問題是：當(dāng)單機(jī) MySQL 無法承載數(shù)據(jù)量或?qū)懭雺毫r，提供一個對應(yīng)用透明的水平擴(kuò)展方案。

TiDB 8.x 在性能、穩(wěn)定性和 MySQL 兼容性上都有顯著提升，TiFlash 列存引擎的成熟使其成為 HTAP（混合事務(wù)分析處理）場景的可行選擇。但 TiDB 不是 MySQL 的直接替代品，它有自己的架構(gòu)約束和使用邊界，盲目遷移會踩很多坑。

1.2 架構(gòu)組件

TiDB 集群由四個核心組件構(gòu)成，每個組件職責(zé)清晰：

TiDB Server：無狀態(tài)的 SQL 層，負(fù)責(zé)解析 SQL、生成執(zhí)行計劃、協(xié)調(diào)事務(wù)?？梢运綌U(kuò)展，多個 TiDB Server 共享同一份數(shù)據(jù)。

TiKV：分布式 KV 存儲，數(shù)據(jù)以 Region（默認(rèn) 96MB）為單位分片，每個 Region 有 3 個副本分布在不同 TiKV 節(jié)點上，通過 Raft 協(xié)議保證一致性。

PD（Placement Driver）：集群的大腦，負(fù)責(zé)存儲集群元數(shù)據(jù)、分配全局唯一時間戳（TSO）、調(diào)度 Region 分布。PD 是強(qiáng)一致的，必須部署奇數(shù)個節(jié)點（通常 3 個）。

TiFlash：列存引擎，異步從 TiKV 同步數(shù)據(jù)，專為 OLAP 查詢優(yōu)化。TiFlash 副本與 TiKV 副本獨立，不影響 OLTP 性能。

1.3 適用場景

單表數(shù)據(jù)量超過 5 億行，MySQL 分庫分表方案維護(hù)成本過高

寫入 TPS 超過單機(jī) MySQL 上限（通常 > 5 萬 TPS）

需要同時支持 OLTP 和實時分析查詢（HTAP）

需要跨地域多活部署，對 RPO/RTO 有嚴(yán)格要求

1.4 環(huán)境要求

二、詳細(xì)步驟

2.1 部署前準(zhǔn)備

2.1.1 系統(tǒng)配置

TiDB 對系統(tǒng)配置有嚴(yán)格要求，以下配置必須在部署前完成：

# 關(guān)閉 swap（TiKV 對內(nèi)存壓力敏感，swap 會導(dǎo)致性能抖動）
swapoff -a
sed -i'/swap/d'/etc/fstab

# 設(shè)置系統(tǒng)參數(shù)
cat >> /etc/sysctl.conf <> /etc/security/limits.conf < /sys/kernel/mm/transparent_hugepage/enabled
echonever > /sys/kernel/mm/transparent_hugepage/defrag
# 持久化
cat >> /etc/rc.local < /sys/kernel/mm/transparent_hugepage/enabled
echonever > /sys/kernel/mm/transparent_hugepage/defrag
EOF

# 檢查 NTP 時間同步（PD 的 TSO 依賴時鐘同步）
timedatectl status
chronyc tracking | grep"System time"
# 要求各節(jié)點時鐘偏差 < 50ms

2.1.2 安裝 TiUP

TiUP 是 TiDB 的官方部署和管理工具，類似于 MySQL 的 mysqladmin：

# 安裝 TiUP（在中控機(jī)上執(zhí)行）
curl --proto'=https'--tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

# 加載環(huán)境變量
source~/.bashrc

# 驗證安裝
tiup --version

# 安裝 cluster 組件
tiup cluster

2.2 集群部署

2.2.1 拓?fù)渑渲梦募?/p>

# 文件路徑：/opt/tidb/topology.yaml
# 最小生產(chǎn)集群：3 PD + 3 TiKV + 2 TiDB

global:
user:"tidb"
ssh_port:22
deploy_dir:"/tidb-deploy"
data_dir:"/tidb-data"
# 日志目錄
log_dir:"/tidb-log"

# 服務(wù)器資源配置
server_configs:
tidb:
 log.slow-threshold:300    # 慢查詢閾值，單位 ms
 performance.max-procs:0    # 0 表示使用所有 CPU
 prepared-plan-cache.enabled:true# 開啟 prepared statement 緩存
 tikv-client.max-batch-wait-time:2000000# 批量請求等待時間，單位 ns

tikv:
 # RocksDB 配置
 rocksdb.defaultcf.block-cache-size:"8GB" # 根據(jù)內(nèi)存調(diào)整，建議內(nèi)存的 30-40%
 rocksdb.writecf.block-cache-size:"2GB"
 # Raft 配置
 raftstore.sync-log:true    # 生產(chǎn)環(huán)境必須開啟
 raftstore.raft-base-tick-interval:"1s"
 # 存儲配置
 storage.reserve-space:"5GB"  # 預(yù)留空間，防止磁盤寫滿導(dǎo)致 TiKV panic

pd:
 replication.max-replicas:3   # 數(shù)據(jù)副本數(shù)
 replication.location-labels:["host"]# 副本分布策略
 schedule.leader-schedule-limit:4
 schedule.region-schedule-limit:2048

pd_servers:
-host:10.0.1.10
-host:10.0.1.11
-host:10.0.1.12

tidb_servers:
-host:10.0.1.13
 port:4000
 status_port:10080
-host:10.0.1.14
 port:4000
 status_port:10080

tikv_servers:
-host:10.0.1.15
 port:20160
 status_port:20180
 config:
  server.labels:{host:"tikv-1"}
-host:10.0.1.16
 port:20160
 status_port:20180
 config:
  server.labels:{host:"tikv-2"}
-host:10.0.1.17
 port:20160
 status_port:20180
 config:
  server.labels:{host:"tikv-3"}

monitoring_servers:
-host:10.0.1.10

grafana_servers:
-host:10.0.1.10

2.2.2 部署和啟動

# 檢查拓?fù)渑渲?tiup cluster check /opt/tidb/topology.yaml --user root

# 自動修復(fù)可修復(fù)的問題
tiup cluster check /opt/tidb/topology.yaml --user root --apply

# 部署集群
tiup cluster deploy tidb-prod v8.1.0 /opt/tidb/topology.yaml --user root

# 啟動集群
tiup cluster start tidb-prod

# 查看集群狀態(tài)
tiup cluster display tidb-prod

# 連接 TiDB（默認(rèn) root 無密碼，立即修改）
mysql -h 10.0.1.13 -P 4000 -u root

# 修改 root 密碼
ALTER USER'root'@'%'IDENTIFIED BY'TiDB@Root2024!';

三、MySQL 兼容性邊界

3.1 支持的功能

TiDB 兼容 MySQL 5.7 協(xié)議，大多數(shù) DDL、DML、事務(wù)操作都能正常使用。以下功能完全支持：

標(biāo)準(zhǔn) SQL（SELECT/INSERT/UPDATE/DELETE/JOIN）

事務(wù)（BEGIN/COMMIT/ROLLBACK，支持悲觀和樂觀兩種模式）

存儲過程、函數(shù)、觸發(fā)器（8.x 版本已基本完善）

分區(qū)表（Range、Hash、List 分區(qū)）

JSON 數(shù)據(jù)類型和函數(shù)

窗口函數(shù)

3.2 不支持或有差異的功能

這是遷移到 TiDB 前必須逐一確認(rèn)的清單：

-- 1. 不支持 FOREIGN KEY 約束（語法不報錯，但不強(qiáng)制執(zhí)行）
-- TiDB 會忽略外鍵約束，應(yīng)用層需要自行保證數(shù)據(jù)完整性

-- 2. 不支持 FULLTEXT 索引
-- 需要改用 Elasticsearch 或其他全文搜索方案

-- 3. AUTO_INCREMENT 行為不同
-- TiDB 的 AUTO_INCREMENT 在分布式環(huán)境下不保證連續(xù)，只保證唯一和遞增
-- 如果業(yè)務(wù)依賴 AUTO_INCREMENT 的連續(xù)性，需要改造
-- 推薦使用 AUTO_RANDOM 替代，避免寫熱點：
CREATETABLEorders (
 idBIGINTAUTO_RANDOM PRIMARYKEY, -- 隨機(jī)分配，避免熱點
  user_idBIGINTNOTNULL,
  created_atTIMESTAMPDEFAULTCURRENT_TIMESTAMP
);

-- 4. 不支持 LOCK TABLES 和 UNLOCK TABLES
-- 需要改用事務(wù)或 SELECT ... FOR UPDATE

-- 5. 不支持 GET_LOCK() / RELEASE_LOCK()
-- 分布式鎖需要用 Redis 或其他方案實現(xiàn)

-- 6. 存儲過程中不支持游標(biāo)的某些用法
-- 建議在應(yīng)用層處理復(fù)雜邏輯

-- 7. 字符集：推薦使用 utf8mb4，其他字符集支持有限

3.3 事務(wù)模式選擇

TiDB 支持兩種事務(wù)模式，選擇錯誤會導(dǎo)致性能問題：

-- 悲觀事務(wù)（默認(rèn)，8.x 版本）：行為與 MySQL 一致，適合高沖突場景
-- 樂觀事務(wù)：提交時才檢測沖突，適合低沖突場景，性能更好但需要處理沖突重試

-- 查看當(dāng)前事務(wù)模式
SHOWVARIABLESLIKE'tidb_txn_mode';

-- 會話級別切換
SETtidb_txn_mode ='optimistic';

-- 全局切換（my.cnf 中配置）
-- tidb_txn_mode = "pessimistic"

四、熱點問題排查

4.1 熱點的成因

TiDB 的數(shù)據(jù)按 Region 分片，每個 Region 有一個 Leader 負(fù)責(zé)讀寫。熱點問題是指大量請求集中到少數(shù)幾個 Region，導(dǎo)致這些 Region 所在的 TiKV 節(jié)點 CPU 和 I/O 打滿，而其他節(jié)點空閑。

常見熱點場景：

AUTO_INCREMENT 寫熱點：順序遞增的主鍵導(dǎo)致新數(shù)據(jù)總是寫入最后一個 Region

時間序列寫熱點：按時間排序的數(shù)據(jù)（日志、訂單）寫入模式與 AUTO_INCREMENT 類似

熱門數(shù)據(jù)讀熱點：某些 key 被頻繁讀?。衢T商品、用戶信息）

4.2 熱點排查

-- 通過 TiDB Dashboard 查看熱點（推薦）
-- 訪問 http://10.0.1.10:2379/dashboard

-- 通過 SQL 查看熱點 Region
SELECT*FROMinformation_schema.TIKV_REGION_STATUS
WHEREIS_INDEX =0
ORDERBYWRITTEN_BYTESDESC
LIMIT20;

-- 查看熱點表
SELECTTABLE_NAME, WRITTEN_BYTES, READ_BYTES
FROMinformation_schema.TIKV_REGION_STATUS
WHEREIS_INDEX =0
ORDERBYWRITTEN_BYTES + READ_BYTESDESC
LIMIT10;

-- 查看 Region 分布是否均勻
SELECTSTORE_ID,COUNT(*)asregion_count
FROMinformation_schema.TIKV_REGION_STATUS
GROUPBYSTORE_ID
ORDERBYregion_countDESC;

4.3 熱點解決方案

-- 方案一：使用 AUTO_RANDOM 替代 AUTO_INCREMENT（推薦）
-- AUTO_RANDOM 在高位隨機(jī)填充，數(shù)據(jù)均勻分布到所有 Region
ALTERTABLEordersMODIFYCOLUMNidBIGINTAUTO_RANDOM;

-- 方案二：SHARD_ROW_ID_BITS（對已有表）
-- 將行 ID 的高位用于分片，減少熱點
ALTERTABLElogsSHARD_ROW_ID_BITS =4; -- 分成 2^4=16 個分片

-- 方案三：PRE_SPLIT_REGIONS（建表時預(yù)分裂）
-- 建表時就創(chuàng)建多個 Region，避免初始寫入熱點
CREATETABLEevents(
 idBIGINTAUTO_RANDOM PRIMARYKEY,
  event_typeVARCHAR(50),
  created_atTIMESTAMP
) PRE_SPLIT_REGIONS =4; -- 預(yù)分裂為 4 個 Region

-- 方案四：手動分裂熱點 Region
-- 找到熱點 Region ID 后手動分裂
-- 通過 TiDB Dashboard 或 pd-ctl 操作

五、故障排查和監(jiān)控

5.1 Dashboard 監(jiān)控關(guān)鍵指標(biāo)

TiDB Dashboard（內(nèi)置于 PD）提供了最直觀的監(jiān)控視圖，訪問地址：http://:2379/dashboard

關(guān)鍵監(jiān)控面板：

Overview 面板：
- QPS：每秒查詢數(shù)，區(qū)分 SELECT/INSERT/UPDATE/DELETE
- Latency：P99 延遲，正常應(yīng) < 100ms
- Connection Count：連接數(shù)，接近 max_connections 時告警

TiKV 面板：
- gRPC Duration：TiDB 到 TiKV 的 RPC 延遲，P99 > 50ms 需關(guān)注
- Storage：各 TiKV 節(jié)點的磁盤使用量，不均勻說明有熱點
- Raft Store CPU：Raft 處理 CPU，持續(xù) > 80% 說明寫入壓力過大

PD 面板：
- Region Health：unhealthy region 數(shù)量，正常應(yīng)為 0
- Scheduler：Region 調(diào)度頻率，頻繁調(diào)度說明集群不均衡
- TSO：時間戳分配延遲，P99 > 2ms 需關(guān)注

5.2 慢查詢分析

-- 查看慢查詢?nèi)罩荆═iDB 將慢查詢存儲在系統(tǒng)表中）
SELECTquery_time, parse_time, compile_time, exec_details,
   query,user, db
FROMinformation_schema.SLOW_QUERY
WHEREquery_time >1-- 超過 1 秒
ORDERBYquery_timeDESC
LIMIT20;

-- 分析執(zhí)行計劃
EXPLAINANALYZESELECT*FROMordersWHEREuser_id =12345;

-- 查看是否走了全表掃描
-- 關(guān)注 task 列中的 "TableFullScan"，應(yīng)盡量避免

-- 強(qiáng)制使用索引
SELECT*FROMordersUSEINDEX(idx_user_id)WHEREuser_id =12345;

-- 查看統(tǒng)計信息是否過期（統(tǒng)計信息不準(zhǔn)會導(dǎo)致執(zhí)行計劃退化）
SHOWSTATS_METAWHEREtable_name ='orders';

-- 手動更新統(tǒng)計信息
ANALYZETABLEorders;

5.3 常見問題排查

5.3.1 日志查看

# TiDB Server 日志
tail -f /tidb-log/tidb/tidb.log | grep -i"error|warn"

# TiKV 日志
tail -f /tidb-log/tikv/tikv.log | grep -i"error|slow"

# PD 日志
tail -f /tidb-log/pd/pd.log | grep -i"error|warn"

# 通過 TiUP 查看集群狀態(tài)
tiup cluster display tidb-prod

# 查看組件日志
tiup cluster audit tidb-prod

5.3.2 常見問題

問題一：寫入延遲突然升高

# 檢查 TiKV 磁盤 I/O
iostat -x 1 5

# 檢查是否有 Region 調(diào)度風(fēng)暴
# 訪問 Dashboard -> PD -> Scheduler 面板

# 檢查 RocksDB compaction 是否積壓
grep"compaction"/tidb-log/tikv/tikv.log | tail -20

問題二：事務(wù)沖突導(dǎo)致大量重試

-- 查看事務(wù)沖突統(tǒng)計
SHOWSTATUSLIKE'tidb_txn_retry%';

-- 查看鎖等待情況
SELECT*FROMinformation_schema.DATA_LOCK_WAITS;

-- 查看當(dāng)前活躍事務(wù)
SELECT*FROMinformation_schema.TIDB_TRXWHEREstate ='LockWaiting';

問題三：Region 不均衡

# 使用 pd-ctl 查看 Region 分布
tiup ctl:v8.1.0 pd -u http://10.0.1.10:2379 region --jq'.regions | map(select(.leader.store_id)) | group_by(.leader.store_id) | map({store: .[0].leader.store_id, count: length})'

# 觸發(fā)手動均衡
tiup ctl:v8.1.0 pd -u http://10.0.1.10:2379 operator add balance-region 

5.4 性能監(jiān)控指標(biāo)

5.5 備份與恢復(fù)

# 使用 BR（Backup & Restore）工具進(jìn)行全量備份
tiup br backup full 
 --pd"10.0.1.10:2379"
 --storage"local:///backup/tidb/$(date +%Y%m%d)"
 --log-file /var/log/tidb/br_backup.log 
 --concurrency 4

# 增量備份（基于上次備份的時間點）
tiup br backup full 
 --pd"10.0.1.10:2379"
 --storage"s3://your-bucket/tidb-backup/$(date +%Y%m%d)"
 --s3.endpoint"https://s3.amazonaws.com"
 --log-file /var/log/tidb/br_backup.log

# 恢復(fù)
tiup br restore full 
 --pd"10.0.1.10:2379"
 --storage"local:///backup/tidb/20240101"
 --log-file /var/log/tidb/br_restore.log

# 查看備份信息
tiup br validate decode 
 --field"end-version"
 --storage"local:///backup/tidb/20240101"

六、總結(jié)

6.1 TiFlash HTAP 場景

TiFlash 是 TiDB 的列存引擎，適合在不影響 OLTP 的前提下運行分析查詢：

-- 為表創(chuàng)建 TiFlash 副本
ALTERTABLEordersSETTIFLASH REPLICA1;

-- 查看 TiFlash 同步進(jìn)度
SELECT*FROMinformation_schema.TIFLASH_REPLICA
WHERETABLE_NAME ='orders';

-- 強(qiáng)制查詢走 TiFlash（分析查詢）
SELECT/*+ READ_FROM_STORAGE(TIFLASH[orders]) */
DATE(created_at)asdate,
COUNT(*)asorder_count,
SUM(amount)astotal_amount
FROMorders
WHEREcreated_at >='2024-01-01'
GROUPBYDATE(created_at)
ORDERBYdate;

-- TiDB 優(yōu)化器會自動選擇 TiKV 或 TiFlash
-- OLTP 查詢走 TiKV，OLAP 查詢走 TiFlash

6.2 遷移到 TiDB 的判斷標(biāo)準(zhǔn)

滿足以下條件之一，遷移到 TiDB 才有實際價值：

單表行數(shù)超過 5 億，MySQL 分庫分表方案的跨分片查詢已成為瓶頸

寫入 TPS 持續(xù)超過 3 萬，單機(jī) MySQL 主節(jié)點 CPU 長期 > 80%

需要在同一份數(shù)據(jù)上同時運行 OLTP 和 OLAP，不想維護(hù)兩套數(shù)據(jù)同步鏈路

需要跨地域多活，MySQL 的主從延遲無法滿足 RPO 要求

不適合遷移的場景：數(shù)據(jù)量 < 1TB、寫入 TPS < 1 萬、大量使用外鍵約束、依賴 MySQL 特有的存儲引擎特性。

6.3 技術(shù)要點回顧

架構(gòu)理解先行：TiDB Server 無狀態(tài)、TiKV 存數(shù)據(jù)、PD 管調(diào)度，三者職責(zé)分離，故障排查要對應(yīng)到具體組件

熱點是頭號敵人：AUTO_INCREMENT 在 TiDB 中是反模式，新表一律用 AUTO_RANDOM

兼容性邊界要摸清：外鍵、FULLTEXT、LOCK TABLES 不支持，遷移前必須逐一確認(rèn)

TiFlash 按需開啟：不是所有表都需要 TiFlash 副本，只對有分析查詢需求的表開啟

監(jiān)控要看 Dashboard：TiDB Dashboard 集成了熱點分析、慢查詢、集群拓?fù)?，是日常運維的主要工具

6.4 參考資料

TiDB 8.x 官方文檔

TiDB 最佳實踐

TiKV 架構(gòu)設(shè)計

TiUP 部署文檔

附錄

A. 命令速查表

# 查看集群狀態(tài)
tiup cluster display tidb-prod

# 啟動/停止/重啟集群
tiup cluster start tidb-prod
tiup cluster stop tidb-prod
tiup cluster restart tidb-prod

# 滾動重啟單個組件
tiup cluster restart tidb-prod -R tidb

# 擴(kuò)容（添加新 TiKV 節(jié)點）
tiup cluster scale-out tidb-prod scale-out.yaml

# 縮容（移除 TiKV 節(jié)點，會自動遷移數(shù)據(jù)）
tiup cluster scale-in tidb-prod --node 10.0.1.18:20160

# 升級集群版本
tiup cluster upgrade tidb-prod v8.2.0

# 查看慢查詢
mysql -h 10.0.1.13 -P 4000 -u root -p -e 
"SELECT query_time, query FROM information_schema.SLOW_QUERY ORDER BY query_time DESC LIMIT 10;"

B. 配置參數(shù)詳解

C. 術(shù)語表