分散型データベース 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は計算・ストレージ分離アーキテクチャを採用し、4つのコアコンポーネントで構成されます：

コンポーネントの責務

┌─────────────────────────────────────────────────────┐
│                    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を使用
AUTO_INCREMENT連続性 ⚠️ 保証なし AUTO_ID_CACHEまたはシーケンスを使用
SAVEPOINT ✅ サポート TiDB 6.2+
SELECT ... FOR UPDATE ⚠️ 悲観的ロック 明示的に悲観的トランザクションを有効化

互換性検証スクリプト

-- TiDBバージョンと互換性の確認
SELECT tidb_version();

-- 現在のトランザクションモードの確認
SELECT @@tidb_txn_mode;

-- AUTO_INCREMENT動作の確認
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;

SQLプランマネージメント（SPM）

-- SQLバインディングで最適計画を固定
CREATE SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped'
USING
  SELECT * FROM orders USE INDEX (idx_status_date) WHERE status = 'shipped';

-- 既存のバインディングを確認
SHOW SESSION BINDINGS;

-- バインディングを削除
DROP SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped';

分散型インデックス戦略

分散型データベースのインデックス設計は単一マシンMySQLと大きく異なり、クロスRegionコストとホットスポットリスクを考慮する必要があります。

インデックス設計原則

  1. Regionスキャンの削減：インデックスプレフィックスを分散させ、少数Regionへの集中を回避
  2. インデックス数の制御：各インデックスは書き込みオーバーヘッドとストレージを増加
  3. 複合インデックスを優先：テーブルルックアップを削減、1つの複合インデックスで複数単一カラムインデックスを代替
  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：AUTO_INCREMENT 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';
-- オペレータに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: "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;

-- AUTO_INCREMENTカラムの確認
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
SQL互換 MySQL PostgreSQL
HTAP ネイティブサポート 未サポート
コミュニティ 中国/APAC中心 グローバル
クラウドサービス 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

-- 推奨：バッチコミット
-- アプリ層で大トランザクションを小トランザクションに分割、1バッチ1000〜5000行

Q6：TiDBのライセンスは？

TiDB Server、TiKV、PDはApache 2.0完全オープンソースです。TiFlashもv8.0+でオープンソース化されています。TiDB Cloud（Serverless/Dedicated）は商用サービスです。

まとめ

TiDBは2026年に分散型データベース分野のベンチマーク製品となっています。MySQL互換性、HTAP能力、クラウドネイティブアーキテクチャにより、エンタープライズデータベースアップグレードの理想的な選択肢です。主要ポイントの振り返り：

  1. アーキテクチャ理解：TiDB/TiKV/PD/TiFlash 4コンポーネント協調、計算・ストレージ分離
  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兼容#教程