TiDBとは？MySQL互換の分散SQLの仕組みとHTAP・採用判断を解説

TiDBは、MySQLのプロトコルと構文をそのまま受けながら、内部ではデータを細かく分割して複数ノードへ配る分散SQLデータベースです。開発元はPingCAP、ライセンスはApache License 2.0。アプリケーションから見れば接続先はMySQLのままで、裏側ではキー空間を区切ったRegionという単位がraftで複製され、台数を足すだけで書き込み能力が伸びます。この記事では2026年8月時点の一次情報をもとに、4つのコンポーネントが担う役割、行指向と列指向を1本のSQLで束ねるHTAPの実装、MySQL互換で通らない範囲、そして8.5系LTSのサポート期限から決まる版の選び方を整理し、採用してよい条件と見送る場面を実装者の目線で示します。

まとめ：TiDBの立ち位置と採用可否を分ける3条件

TiDBは「MySQLの代替」ではなく「MySQLのインターフェースを持つ別系統のデータベース」です。SQLとドライバは共通でも、内部はキーバリューストアの上にSQL層を載せた構造で、単一ノードのInnoDBとは動き方が違います。

採用可否は3条件で決まります。第一に、単一インスタンスの書き込み上限に実際にぶつかっているか、あるいは数年内にぶつかる見通しが数値で立っていること。第二に、非対応機能（ストアドプロシージャ・トリガー・イベント）に既存システムが依存していないこと。第三に、TiKVとPDとTiDBサーバを合わせて8ノード規模になる構成を、費用と運用体制の両面で引き受けられること。

実務で止まるのは3つ目です。分水嶺は、分散にする必然性がデータ量ではなく書き込みスループットの側にあるかどうか。読み取りが重いだけならリードレプリカで足り、分散SQLの運用責任を背負う理由になりません。

TiDBの実体｜MySQL互換のまま水平に伸ばす分散SQLデータベース

TiDB・TiKV・PD・TiFlashの4つが分担する役割と配置

TiDBのクラスタは4種類のコンポーネントで構成されます。役割が明確に分かれている点が、単一プロセスで完結するMySQLとの最大の構造差です。

TiDBサーバはMySQLプロトコルの接続口です。クエリを受けて構文解析と実行計画の生成を行い、実際の読み書きはTiKV（またはTiFlash）へ投げる。データを一切持たないため、接続数が足りなければノードを足すだけで済みます。

PD（Placement Driver）はクラスタの頭脳にあたります。どのデータがどのノードにあるかというメタ情報とトポロジを管理し、トランザクションIDを払い出し、TiKVからの配置報告をもとにスケジューリングの指示を出す。ここが単一障害点になると全体が止まるため、高可用構成では3ノード以上が要件です。

TiKVが実データを持つ分散キーバリューストアで、既定でレプリカを3つ保持します。TiFlashだけは任意で、分析クエリを速くする必要が無ければ置かない構成も成り立つ。裏を返せば、TiFlash無しのTiDBは「MySQL互換の分散OLTP」であって、HTAPの側面は使っていないことになります。

RegionとMulti-Raft｜256MiB単位で分けて多数決で書く仕組み

TiKVはキー空間を連続した区間に切り分けて管理します。この区間がRegionで、左閉右開の[StartKey, EndKey)で表される。Regionの既定サイズ上限は256MiBで、設定で変更できます。上限を超えたRegionは自動的に分割され、PDの指示で別ノードへ移動する。

各Regionが独立したraftグループを構成する点が要です。グループ内の1つがリーダーとなって読み書きを受け、フォロワーへ複製する。書き込みは過半数のノードへ届いた時点で確定するため、3レプリカなら1ノードの障害では止まりません。この「Regionごとにraftグループを持つ」構造がMulti-Raftと呼ばれるもので、クラスタ全体で1つの合意形成を回す設計に比べ、書き込みが並列に流れます。

永続化そのものはRocksDBが担い、MVCCはキーにバージョン番号を付けて実現されます。分散トランザクションはGoogle BigTableのPercolatorモデルを踏襲した2フェーズコミットで、PDが払い出す単調増加のタイムスタンプがバージョンの順序づけに使われる。設計上の帰結として、トランザクションの開始とコミットのたびにPDへの往復が入るため、極端に短いトランザクションを大量に流す構成ではPDがボトルネックになり得ます。

HTAPの実装｜行指向TiKVと列指向TiFlashを1本のSQLで束ねる

TiFlashへの複製とオプティマイザによる自動振り分けの動作

TiDBがHTAPを名乗る根拠は、性質の違うストレージエンジンを2つ同時に持てることにあります。TiKVが行指向でトランザクション処理を担い、TiFlashが同じデータを列指向で保持して集計を担う。OLTPとOLAPの役割の違いを前提に読むと構造が掴みやすいところです。

TiFlashへの複製はテーブル単位で指定します。有効にしたテーブルはraftのログを経由してTiFlash側へ反映され、非同期ながら遅延の小さい複製になる。ここが従来型のETLと決定的に違う点で、日次バッチでDWHへ流す構成のような数時間単位のずれが入りません。

クエリの振り分けはオプティマイザが自動で判断します。全件走査を伴う集計は列指向のTiFlashへ、主キー検索や少数行の更新は行指向のTiKVへ。同じSQLの中で両者を混ぜた実行計画も組めるため、アプリケーション側で接続先を切り替えるコードは要りません。

分析クエリを本番データベースに同居させてよい条件と分離する基準

ただし「同居できる」ことと「同居させるべき」ことは別です。同居させてよいのは、分析対象が本番データそのもので、かつ集計結果の鮮度が分単位で求められる場面に限られます。在庫の即時集計、不正検知のスコアリング、管理画面のリアルタイム指標といった用途がここに当たる。

分離すべき条件も明確です。分析対象が複数システムを横断していて結合が要るなら、TiFlashではなくデータウェアハウス側の仕事になります。過去数年分の履歴を保持する要件があるなら、本番クラスタのストレージ費用に直結するため分離が妥当。そして分析の実行者が社内の非エンジニアで、書き手が制御できないクエリが流れる構成も分けるべきです。TiFlashはリソース制御の仕組みを持つとはいえ、同一クラスタである以上は影響が完全には切れません。

当社ではデータ分析基盤構築・MLOps構築支援として、この「同居か分離か」の線引きを含めたデータベース選定から構築・運用体制づくりまでを受託しています。

MySQL互換の実際の範囲｜そのまま通るものと書き換えが要るもの

非対応機能の一覧｜ストアドプロシージャ・トリガー・全文索引ほか

互換対象はMySQL 5.7および8.0のプロトコルと構文です。JDBCやORM、マイグレーションツールは接続レベルでそのまま動き、SELECT・INSERT・UPDATE・DELETEの範囲で書き換えが発生する場面はほとんどありません。MySQL側のバージョン選定を済ませた案件なら、移行の入口は低いところです。

問題は非対応機能に当たったときです。以下は移行判定で必ず洗い出す項目になります。

受託案件で効くのはストアドプロシージャとトリガーです。基幹系の移行では業務ロジックがデータベース側に溜まっている構成が珍しくなく、この2つが移行工数の大半を占める。全文索引についてもTiDB Cloud Starterで限定的な対応がある一方、セルフホストでは別の検索基盤を立てる前提になります。文字セットもascii・latin1・binary・utf8・utf8mb4・gbkに限られ、それ以外を使っている既存スキーマは変換が要ります。

挙動差｜AUTO_INCREMENTの非連続と外部キーのv8.5でのGA

構文が通っても挙動が違う項目のほうが事故になりやすいところです。代表がAUTO_INCREMENTで、値は全体で一意になるものの、複数のTiDBサーバが並ぶ構成では連番になりません。IDの連続性を業務要件にしている画面や帳票は、この時点で作り直しになります。

外部キー制約はv6.6.0で導入され、v8.5.0でGAとなりました。カスケード動作にも対応しています。旧版を前提にした「TiDBは外部キーが使えない」という解説が日本語圏には残っているため、判断材料にする前に対象バージョンを確認してください。

ほかに押さえる差分が4つ。ビューへの書き込み（UPDATE・INSERT・DELETE）はできません。性能スキーマは多くのテーブルが結果を返さないため、既存の監視スクリプトは組み替えが要る。既定の文字セットはutf8mb4、照合順序はutf8mb4_binで、MySQL 5.7のlatin1既定とは異なります。lower_case_table_namesの既定は2で、テーブル名の照合が大文字小文字を区別しない挙動になる。1つのDDL文で同じ列や索引を複数回変更できない制約もあり、移行スクリプトの分割が必要になる場面があります。

提供形態｜セルフホストとTiDB Cloudの3プランをどう選ぶか

8.5系LTSとサポート期限で決まる本番環境で選ぶ版の判断基準

本番で選ぶ版はLTSから決めます。2026年8月時点の現行LTSは8.5系で、8.5.0のGAが2024年12月19日。以降のパッチは8.5.5が2026年1月15日、8.5.6が2026年4月14日、8.5.7が2026年7月9日と続いており、8.5より上位のメジャー系列はまだ出ていません。

判断は単純です。新規構築は8.5系のエンタープライズかコミュニティを選び、v7.5以下で動いている既存クラスタは期限から逆算して移行計画を立てる。特にv7.1とv6.5はメンテナンスが終わっており、セキュリティ修正の提供範囲が絞られる段階に入っています。

8.5系で入った変更のうち運用に効くのは3点です。外部キーのGA、PDフォロワーがRegion情報の問い合わせを処理するActive PD Followersによるリーダー側のCPU負荷軽減、そして既定で有効になったテーブル作成の高速化。非互換事項として、非strictモードでNOT NULL列にNULLを挿入するとエラーを返す挙動へ変わった点と、CentOS 7およびRed Hat Enterprise Linux 7のサポート終了（Rocky Linux 9.1以降が推奨）があります。ベクトル検索とTiProxyのトラフィック再生は8.5系の時点で実験的機能の扱いです。

セルフホストとTiDB Cloud｜運用主体で分かれる3つの選択肢

提供形態は大きく2系統。Apache License 2.0のオープンソース版を自分で構築するセルフホストと、PingCAPが運用するマネージドのTiDB Cloudです。後者はStarter（2025年にTiDB Serverlessから改称）、Essential、Dedicatedの3プランに分かれます。

選び方の軸は運用主体です。TiKVのraft複製、PDのスケジューリング、ローリングアップグレードの版差管理を引き受ける要員が社内にいるならセルフホストが選べる。いないならマネージド一択で、検証や小規模ならStarter、本番の専有構成ならDedicatedという分岐になります。プラン別の料金体系とオートスケールの内部動作はTiDB Cloud Starterの料金とオートスケールの解説に整理しているため、費用の見積もり段階ではそちらを参照してください。

採用してよい条件と見送る場面｜Aurora・Spannerとの選び分け

採用してよい3条件と、分散SQLが過剰投資に終わる案件の見分け方

採用してよいのは、次の3条件のいずれかに当てはまる案件です。第一に、単一インスタンスの書き込み上限に実際に到達していて、シャーディングをアプリケーション側で実装する以外に手が無い状態。TiDBはシャーディング機構をエンジン内部に持つため、アプリ側からは1つのMySQLに見えます。第二に、MySQL資産を抱えたまま台数で伸ばしたい要件。第三に、鮮度の高い集計を本番データに対して直接かけたい要件です。

見送るべき場面もはっきりしています。データ量が数百GB規模で、単一のマネージドRDBで捌けている業務システムには持ち込まないでください。得られるのは将来の拡張余地だけで、代わりに8ノード規模のクラスタと分散データベースの運用責任を引き受けることになります。前提から整理し直したいならRDBとNoSQLの選び方から入るほうが早いところです。

もう1つの見送り条件が、業務ロジックをストアドプロシージャとトリガーに集約している基幹系です。移行できないわけではないものの、ロジックをアプリケーション層へ移す工程が本体になり、データベース移行の見積もりが実質的にシステム再構築の見積もりへ変わります。この場合はAmazon AuroraのようなMySQL互換のマネージドへ寄せるほうが、費用対効果は読みやすいところです。

Aurora・Spanner・CockroachDBとの比較と選定の分岐点

決め手になるのは性能値よりも、互換インターフェースと動かせる場所です。

選定はこう分岐します。既存資産がPostgreSQLなら、MySQL互換のTiDBではなくCockroachDBが第一候補。インフラがGoogle Cloudに固定されていて運用を外に出したいならCloud Spannerで、AWS固定ならAmazon Auroraです。

TiDBが勝つのは、MySQL資産があり、クラウドを跨ぐ配置か自己ホストが要件に入っていて、かつ書き込みスループットの成長が数値で見えている案件。逆に言えば、その3つが揃わない状態で「MySQLのままスケールできるから」という理由だけで選ぶと、増えたノードの運用コストだけが残ります。

TiDBの採用検討でよくある質問と移行前に確認しておきたい前提

導入の相談でよく挙がる質問を、公式ドキュメントの記載から整理しました。

TiDBは無料で使えますか？

セルフホストのTiDBはApache License 2.0のオープンソースで、機能制限や容量の上限なく無償で使えます。費用がかかるのはインフラとPingCAPの商用サポート、そしてマネージドのTiDB Cloudを選んだ場合の利用料です。ソースコード公開の条件が付くソースアベイラブル系のライセンスとは異なり、商用利用の制約は実質的にありません。

MySQLからそのまま移行できますか？

SELECTやINSERTといった通常のSQLはほぼそのまま通ります。書き換えが要るのはストアドプロシージャ、トリガー、イベント、ユーザー定義関数、全文索引、空間索引を使っている箇所です。挙動差ではAUTO_INCREMENTが複数サーバ間で連番にならない点、ビューへの書き込みができない点、既定の照合順序がutf8mb4_binである点を移行前に洗い出してください。

最小構成は何ノード必要ですか？

高可用を確保するならPDが3ノード、TiKVが3ノード、TiDBサーバが2ノード以上で、合計8ノード規模が目安になります。TiKVは既定でレプリカを3つ持つため、3ノードを下回ると冗長性が成り立ちません。この台数が引き受けられないなら、マネージドのTiDB Cloudを選ぶか、分散にしない構成を検討する段階です。

TiFlashは必ず必要ですか？

不要です。TiFlashは列指向で分析を速くするための任意コンポーネントで、置かなければMySQL互換の分散OLTPとして動きます。導入判断の基準は、全件走査を伴う集計を本番データに対して直接かけたいかどうか。日次バッチでデータウェアハウスへ流す運用で足りているなら、TiFlashを置かずに始めて後から追加する順序で構いません。

どのバージョンを本番で選ぶべきですか？

2026年8月時点ではLTSの8.5系です。8.5.0のGAが2024年12月19日で、直近のパッチは8.5.7（2026年7月9日）。コミュニティ版のメンテナンス期限は2027年12月19日、エンタープライズ版は2029年12月19日まで続きます。v7.1とv6.5はメンテナンスが終了済みのため新規採用の対象から外し、v7.5で稼働中のクラスタは2026年12月1日の期限から逆算して移行計画を立ててください。

関連記事

• TiDB Serverlessとは？TiDB Cloud Starter改称・料金・オートスケール解説：マネージド版の料金体系とオートスケールの内部動作を詳述しています。
• CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説：PostgreSQL互換側の分散SQLとして対になる候補です。
• Cloud Spannerとは？分散リレーショナルDBの仕組み・TrueTimeと採用判断を実装者目線で解説：Google Cloud固定の案件で比較対象になります。
• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説：AWS上でMySQL互換を維持する場合の第一候補です。
• MySQLとは？特徴とバージョン選定・採用判断を実装目線で解説：移行元となるMySQL側の前提整理に使えます。
• OLTPとは｜OLAP・DWHとの違いとHTAP・AWS DB選定を比較解説：HTAPという言葉の位置づけを押さえる前提記事です。
• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説：そもそも分散SQLを選ぶべきかを整理する土台です。