--- title: "TiDBとは：MySQL互換の分散SQLの仕組みとHTAP・検証手順・採用判断を解説" url: "https://www.issoh.co.jp/tech/details/16005/" published: 2026-08-01 updated: 2026-10-23 categories: ["データベース"] publisher: "株式会社一創" --- # TiDBとは：MySQL互換の分散SQLの仕組みとHTAP・検証手順・採用判断を解説 TiDBは、MySQLのプロトコルと構文をそのまま受けながら、内部ではデータを細かく分割して複数ノードへ配る分散SQLデータベースです。開発元はPingCAP、ライセンスはApache License 2.0。アプリケーションから見れば接続先はMySQLのままで、裏側ではキー空間を区切ったRegionという単位がraftで複製され、台数を足すだけで書き込み能力が伸びます。この記事では2026年9月時点の一次情報をもとに、4つのコンポーネントが担う役割、TiUPで手元に検証クラスタを立てて接続するまでの手順、行指向と列指向を1本のSQLで束ねるHTAPの実装、MySQL互換で通らない範囲、そして8.5系LTSのサポート期限から決まる版の選び方を整理し、採用してよい条件と見送る場面を実装者の目線で示します。 ## まとめ：TiDBの立ち位置と採用可否を分ける3条件 TiDBは「MySQLの代替」ではなく「MySQLのインターフェースを持つ別系統のデータベース」です。SQLとドライバは共通でも、内部はキーバリューストアの上にSQL層を載せた構造で、単一ノードのInnoDBとは動き方が違います。 採用可否は3条件で決まります。第一に、単一インスタンスの書き込み上限に実際にぶつかっているか、あるいは数年内にぶつかる見通しが数値で立っていること。第二に、非対応機能（ストアドプロシージャ・トリガー・イベント）に既存システムが依存していないこと。第三に、TiKVとPDとTiDBサーバを合わせて8ノード規模になる構成を、費用と運用体制の両面で引き受けられること。 実務で止まるのは3つ目です。分水嶺は、分散にする必然性がデータ量ではなく書き込みスループットの側にあるかどうか。読み取りが重いだけならリードレプリカで足り、分散SQLの運用責任を背負う理由になりません。 判断を紙の上だけで進めないでください。TiUPのplaygroundを使えば1台のマシンにTiDBサーバ2・PD3・TiKV3の構成が数分で立ち上がり、手持ちのスキーマとクエリをそのまま流して互換性の当たりを取れます。本記事では後半にその手順とコマンドを置きました。 ## TiDBの実体｜MySQL互換のまま水平に伸ばす分散SQLデータベース ### TiDB・TiKV・PD・TiFlashの4つが分担する役割と配置 TiDBのクラスタは4種類のコンポーネントで構成されます。役割が明確に分かれている点が、単一プロセスで完結するMySQLとの最大の構造差です。分担の定義はPingCAPの[TiDBアーキテクチャ解説](https://docs.pingcap.com/tidb/stable/tidb-architecture/)に一次情報として置かれています。 | コンポーネント | 役割 | 状態 | 最小構成の目安 | | ------- | ------------- | ------- | -------- | | TiDBサーバ | SQL解析と実行計画の生成 | ステートレス | 2ノード以上 | | PD | 配置管理とID払い出し | メタ情報を保持 | 3ノード以上 | | TiKV | 行指向のデータ保存 | データ本体 | 3ノード以上 | | TiFlash | 列指向で分析を処理 | 複製データ | 任意（0でも可） | TiDBサーバはMySQLプロトコルの接続口です。クエリを受けて構文解析と実行計画の生成を行い、実際の読み書きはTiKV（またはTiFlash）へ投げる。データを一切持たないため、接続数が足りなければノードを足すだけで済みます。 PD（Placement Driver）はクラスタの頭脳にあたります。どのデータがどのノードにあるかというメタ情報とトポロジを管理し、トランザクションIDを払い出し、TiKVからの配置報告をもとにスケジューリングの指示を出す。ここが単一障害点になると全体が止まるため、高可用構成では3ノード以上が要件です。 TiKVが実データを持つ分散キーバリューストアで、既定でレプリカを3つ保持します。TiFlashだけは任意で、分析クエリを速くする必要が無ければ置かない構成も成り立つ。裏を返せば、TiFlash無しのTiDBは「MySQL互換の分散OLTP」であって、HTAPの側面は使っていないことになります。エンジンを分けずに列ストア側へ点参照を足す対抗実装は、[SingleStoreのUniversal Storage](https://www.issoh.co.jp/tech/details/16452/)で扱っています。 ### RegionとMulti-Raft｜256MiB単位で分けて多数決で書く仕組み TiKVはキー空間を連続した区間に切り分けて管理します。この区間がRegionで、左閉右開の`[StartKey, EndKey)`で表される。Regionの既定サイズ上限は256MiBで、設定で変更できます。上限を超えたRegionは自動的に分割され、PDの指示で別ノードへ移動する。この分割と移動をPDがどの情報をもとに決めているかは、公式の[TiDBのスケジューリング仕様](https://docs.pingcap.com/tidb/stable/tidb-scheduling/)に判断材料（ストア残容量・リーダー数・レプリカ数）まで書かれています。 各Regionが独立したraftグループを構成する点が要です。グループ内の1つがリーダーとなって読み書きを受け、フォロワーへ複製する。書き込みは過半数のノードへ届いた時点で確定するため、3レプリカなら1ノードの障害では止まりません。この「Regionごとにraftグループを持つ」構造がMulti-Raftと呼ばれるもので、クラスタ全体で1つの合意形成を回す設計に比べ、書き込みが並列に流れます。 永続化そのものはRocksDBが担い、MVCCはキーにバージョン番号を付けて実現されます。分散トランザクションはGoogle BigTableのPercolatorモデルを踏襲した2フェーズコミットで、PDが払い出す単調増加のタイムスタンプがバージョンの順序づけに使われる。設計上の帰結として、トランザクションの開始とコミットのたびにPDへの往復が入るため、極端に短いトランザクションを大量に流す構成ではPDがボトルネックになり得ます。 ## 検証環境の構築｜TiUPで1台のマシンにTiDBクラスタを立てる手順 ### TiUPのインストールとplaygroundによるクラスタ起動コマンド TiDBの構築と運用はTiUPというコンポーネント管理ツールに集約されています。検証だけならクラウドの契約も8台のサーバも要りません。playgroundサブコマンドが、1台のマシン上にTiDBサーバ・PD・TiKVのプロセスを指定した数だけ起動します。手順の一次情報は[TiDB Self-Managedのクイックスタート](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb/)にあり、macOSとLinuxが対象です。 ``` curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh source ~/.bash_profile tiup playground v8.5.8 --db 2 --pd 3 --kv 3 ``` 3行目の引数が本番の最小構成をそのまま写したものです。TiDBサーバ2、PD3、TiKV3。バージョンを省くと最新の安定版が選ばれますが、判定したい版を明示するほうが結果を再現できます。起動が終わると接続先のポート（既定で4000）とダッシュボードのURLが標準出力に出ます。 ### mysqlクライアントでの接続確認とスキーマ投入までの動作確認 接続には既存のmysqlクライアントをそのまま使います。ドライバもツールもMySQL向けのものが通る、という主張を最初に確かめられる工程です。 ``` mysql --host 127.0.0.1 --port 4000 -u root SELECT tidb_version(); CREATE DATABASE demo; CREATE TABLE demo.sales (id BIGINT PRIMARY KEY AUTO_INCREMENT, shop_id INT, amount DECIMAL(12,2), created_at DATETIME); SHOW CREATE TABLE demo.sales; ``` `tidb_version()`はMySQLに無い関数で、接続先がTiDBであることと起動した版を同時に返します。移行判定の下見をここで済ませてください。既存システムのDDLをまとめて流し、通らなかった文を記録する。ストアドプロシージャやトリガーを含むダンプなら、この時点で構文エラーとして落ちます。検証を畳むときは`tiup clean --all`でプロセスとデータをまとめて破棄できます。 ## HTAPの実装｜行指向TiKVと列指向TiFlashを1本のSQLで束ねる ### TiFlashへの複製とオプティマイザによる自動振り分けの動作 TiDBがHTAPを名乗る根拠は、性質の違うストレージエンジンを2つ同時に持てることにあります。TiKVが行指向でトランザクション処理を担い、TiFlashが同じデータを列指向で保持して集計を担う。[OLTPとOLAPの役割の違い](https://www.issoh.co.jp/tech/details/9237/)を前提に読むと構造が掴みやすいところです。 TiFlashへの複製はテーブル単位で指定します。有効にしたテーブルはraftのログを経由してTiFlash側へ反映され、非同期ながら遅延の小さい複製になる。ここが従来型のETLと決定的に違う点で、日次バッチでDWHへ流す構成のような数時間単位のずれが入りません。 クエリの振り分けはオプティマイザが自動で判断します。全件走査を伴う集計は列指向のTiFlashへ、主キー検索や少数行の更新は行指向のTiKVへ。同じSQLの中で両者を混ぜた実行計画も組めるため、アプリケーション側で接続先を切り替えるコードは要りません。 ### TiFlash複製の有効化と実行計画が切り替わるまでの確認コマンド 「自動で振り分く」という説明は、実行計画を出せば数分で裏が取れます。複製の指定はDDL1文、進捗はシステムテーブルの参照、切り替わりの確認はEXPLAINです。構文と読み取り経路の指定方法は[TiFlashの利用方法](https://docs.pingcap.com/tidb/stable/use-tiflash/)に載っています。 ``` ALTER TABLE demo.sales SET TIFLASH REPLICA 2; SELECT TABLE_NAME, REPLICA_COUNT, PROGRESS, AVAILABLE FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'demo'; EXPLAIN SELECT shop_id, SUM(amount) FROM demo.sales GROUP BY shop_id; EXPLAIN SELECT * FROM demo.sales WHERE id = 1; ``` 2行目の`AVAILABLE`が1になるまで、複製は実行計画の候補に入りません。ここを待たずにEXPLAINを叩いて「TiFlashが使われない」と判断する取り違えが起きます。3行目の集計クエリでは実行計画にmpp taskとTiFlashのテーブルスキャンが現れ、4行目の主キー検索はPoint\_Getのまま。同じテーブルに対する2本のクエリで経路が分かれることが、そのまま確認になります。 ### 分析クエリを本番データベースに同居させてよい条件と分離する基準 ただし「同居できる」ことと「同居させるべき」ことは別です。同居させてよいのは、分析対象が本番データそのもので、かつ集計結果の鮮度が分単位で求められる場面に限られます。在庫の即時集計、不正検知のスコアリング、管理画面のリアルタイム指標といった用途がここに当たる。 分離すべき条件も明確です。分析対象が複数システムを横断していて結合が要るなら、TiFlashではなくデータウェアハウス側の仕事になります。過去数年分の履歴を保持する要件があるなら、本番クラスタのストレージ費用に直結するため分離が妥当。そして分析の実行者が社内の非エンジニアで、書き手が制御できないクエリが流れる構成も分けるべきです。TiFlashはリソース制御の仕組みを持つとはいえ、同一クラスタである以上は影響が完全には切れません。 当社では[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)として、この「同居か分離か」の線引きを含めたデータベース選定から構築・運用体制づくりまでを受託しています。 ## MySQL互換の実際の範囲｜そのまま通るものと書き換えが要るもの ### 非対応機能の一覧｜ストアドプロシージャ・トリガー・全文索引ほか 互換対象はMySQL 5.7および8.0のプロトコルと構文です。JDBCやORM、マイグレーションツールは接続レベルでそのまま動き、SELECT・INSERT・UPDATE・DELETEの範囲で書き換えが発生する場面はほとんどありません。[MySQL側のバージョン選定](https://www.issoh.co.jp/tech/details/13135/)を済ませた案件なら、移行の入口は低いところです。 問題は非対応機能に当たったときです。以下は移行判定で必ず洗い出す項目で、原典は[MySQLとの互換性](https://docs.pingcap.com/tidb/stable/mysql-compatibility/)のページになります。 | 分類 | 非対応の内容 | 移行時の対処 | | ---- | -------------- | ----------- | | 手続き型 | ストアドプロシージャ | アプリ層へ移設 | | 手続き型 | トリガー・イベント | アプリ層かジョブへ移設 | | 関数 | ユーザー定義関数 | アプリ層で再実装 | | 索引 | FULLTEXT・降順索引 | 検索基盤を別立て | | 空間 | SPATIAL・GIS関数 | 別データベースへ分離 | | 構文 | SKIP LOCKED・XA | ロック設計を見直し | 受託案件で効くのはストアドプロシージャとトリガーです。基幹系の移行では業務ロジックがデータベース側に溜まっている構成が珍しくなく、この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年9月時点の現行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が2026年8月27日と続いています。次期メジャーはv9.0.0-beta.1が2025年3月に出たきりで、GAに至った上位系列は[pingcap/tidbのリリース一覧](https://github.com/pingcap/tidb/releases)にまだ現れていません。 | 版 | メンテナンス期限 | EOL | 新規採用の可否 | | -------------- | ----------- | ----------- | ------- | | v8.5（コミュニティ） | 2027年12月19日 | 2028年12月19日 | 推奨 | | v8.5（エンタープライズ） | 2029年12月19日 | 2030年12月19日 | 推奨 | | v8.1 | 2027年5月24日 | 2028年5月24日 | 既存のみ | | v7.5 | 2026年12月1日 | 2027年12月1日 | 移行を計画 | | v7.1 | 終了済み | 2027年5月31日 | 不可 | | v6.5 | 終了済み | 2026年12月29日 | 不可 | この期限はPingCAPの[TiDBリリースサポートポリシー](https://www.pingcap.com/tidb-release-support-policy/)に一覧で公開されており、メンテナンス期間の後にさらに1年の延長サポート（重大なセキュリティ修正のみ）が付く二段構えになっています。判断は単純です。新規構築は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の料金とオートスケールの解説](https://www.issoh.co.jp/tech/details/7541/)に整理しているため、費用の見積もり段階ではそちらを参照してください。 ## 採用してよい条件と見送る場面｜Aurora・Spannerとの選び分け ### 採用してよい3条件と、分散SQLが過剰投資に終わる案件の見分け方 採用してよいのは、次の3条件のいずれかに当てはまる案件です。第一に、単一インスタンスの書き込み上限に実際に到達していて、シャーディングをアプリケーション側で実装する以外に手が無い状態。TiDBはシャーディング機構をエンジン内部に持つため、アプリ側からは1つのMySQLに見えます。自前で分割層を組む場合の設計と比べたい場合は[シャーディングとは？水平分割の仕組みと採用判断](https://www.issoh.co.jp/tech/details/16274/)を参照してください。第二に、MySQL資産を抱えたまま台数で伸ばしたい要件。第三に、鮮度の高い集計を本番データに対して直接かけたい要件です。 見送るべき場面もはっきりしています。データ量が数百GB規模で、単一のマネージドRDBで捌けている業務システムには持ち込まないでください。得られるのは将来の拡張余地だけで、代わりに8ノード規模のクラスタと分散データベースの運用責任を引き受けることになります。前提から整理し直したいなら[RDBとNoSQLの選び方](https://www.issoh.co.jp/tech/details/13012/)から入るほうが早いところです。 もう1つの見送り条件が、業務ロジックをストアドプロシージャとトリガーに集約している基幹系です。移行できないわけではないものの、ロジックをアプリケーション層へ移す工程が本体になり、データベース移行の見積もりが実質的にシステム再構築の見積もりへ変わります。この場合は[Amazon Aurora](https://www.issoh.co.jp/tech/details/15447/)のようなMySQL互換のマネージドへ寄せるほうが、費用対効果は読みやすいところです。 ### Aurora・Spanner・CockroachDBとの比較と選定の分岐点 決め手になるのは性能値よりも、互換インターフェースと動かせる場所です。 | 製品 | 互換インターフェース | 動かせる場所 | ライセンス・提供形態 | | ------------- | ---------------- | -------------- | ---------------- | | TiDB | MySQL 5.7・8.0 | 自己ホスト・各クラウド | Apache-2.0 | | CockroachDB | PostgreSQL | 自己ホスト・各クラウド | Source Available | | Cloud Spanner | 独自・PostgreSQL方言 | Google Cloudのみ | マネージド専用 | | Amazon Aurora | MySQL・PostgreSQL | AWSのみ | マネージド専用 | 選定はこう分岐します。既存資産がPostgreSQLなら、MySQL互換のTiDBではなく[CockroachDB](https://www.issoh.co.jp/tech/details/16002/)が第一候補。インフラがGoogle Cloudに固定されていて運用を外に出したいなら[Cloud Spanner](https://www.issoh.co.jp/tech/details/15544/)で、AWS固定なら[Amazon Aurora](https://www.issoh.co.jp/tech/details/15447/)です。 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年9月時点ではLTSの8.5系です。8.5.0のGAが2024年12月19日で、直近のパッチは8.5.8（2026年8月27日）。コミュニティ版のメンテナンス期限は2027年12月19日、エンタープライズ版は2029年12月19日まで続きます。v7.1とv6.5はメンテナンスが終了済みのため新規採用の対象から外し、v7.5で稼働中のクラスタは2026年12月1日の期限から逆算して移行計画を立ててください。 ## 関連記事 - [TiDB Serverlessとは？TiDB Cloud Starter改称・料金・オートスケール解説](https://www.issoh.co.jp/tech/details/7541/)：マネージド版の料金体系とオートスケールの内部動作を詳述しています。 - [CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/16002/)：PostgreSQL互換側の分散SQLとして対になる候補です。 - [Cloud Spannerとは？分散リレーショナルDBの仕組み・TrueTimeと採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15544/)：Google Cloud固定の案件で比較対象になります。 - [Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15447/)：AWS上でMySQL互換を維持する場合の第一候補です。 - [MySQLとは？特徴とバージョン選定・採用判断を実装目線で解説](https://www.issoh.co.jp/tech/details/13135/)：移行元となるMySQL側の前提整理に使えます。 - [OLTPとは｜OLAP・DWHとの違いとHTAP・AWS DB選定を比較解説](https://www.issoh.co.jp/tech/details/9237/)：HTAPという言葉の位置づけを押さえる前提記事です。 - [データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説](https://www.issoh.co.jp/tech/details/13012/)：そもそも分散SQLを選ぶべきかを整理する土台です。 - [TiDB Cloud不正アクセスの範囲と対応：APIキー交換と監査ログ確認の手順](https://www.issoh.co.jp/tech/details/18773/)：TiDB Cloudの不正アクセスで利用企業が行う対応です。 --- 出典: [TiDBとは：MySQL互換の分散SQLの仕組みとHTAP・検証手順・採用判断を解説]()（株式会社一創）