TiDBのパフォーマンス・ホットスポット：Top SQLで問題を特定し解決する方法

※このブログは2025年3月27日に公開された英語ブログ ｢TiDB Performance Hotspots: How to Identify and Fix Issues Using Top SQL｣ の拙訳です。

ホットスポットは分散データベースにおける隠れた性能低下の要因です。アラートを発することはほとんどなく、その代わりにスループットに継続的な悪影響を与え、テイルレイテンシ (遅延の最大値) を増大させ、エンジニアチームを混乱させます。もし大規模にTiDBを運用していて、突然あるTiKVノードだけが高負荷になり、他のノードがほとんどアイドル状態になっているようであれば、それはホットスポットが発生している可能性が高いと言えるでしょう。

このブログでは、TiDB Dashboard、Top SQL、システムテーブルを使ってTiDBのホットスポットの特定と、診断方法を解説します。スキーマ設計の問題、インデックスの癖、特定のキーへのトラフィックの集中など、原因が何であれ、問題の兆候を早期に察知し、迅速に対処する方法をお伝えします。

TiDBにおけるパフォーマンスホットスポットの理解

TiDBのような分散型SQLデータベースでは、データは ｢リージョン｣ と呼ばれるキー空間の小さな単位に分割され、複数のストレージノード (TiKVやTiFlash) に分散されます。しかし、その一部のデータにトラフィックが集中しすぎると、特定のノードだけに過剰な負荷がかかってしまいます。
こうした「ホットスポット」は、スループットと応答時間の低下を引き起こすパフォーマンスのボトルネックを生み出します。

ホットスポットの主な原因は2つあります：

• データの偏り (Data Skew)：リージョン間でデータが均等に分散されておらず、特定のリージョンに偏ってしまうケースです。これは多くの場合、スキーマ設計が原因となります。
  例えば：

CREATE TABLE t (
    a BIGINT PRIMARY KEY AUTO_INCREMENT, 
    b VARCHAR(255)
);

このスキーマでは、カラムAに対してデータを連続的に挿入しており、新しい行が同じリージョンに集中します。その結果、特定のTiKVノードに書き込みが集中し、徐々に書き込みホットスポットが発生します。一方で他のノードはあまり活用されません。

• ホットキーアクセス (Hot Key Access)：少数の行、あるいは単一のキーへのアクセスが集中するケースです。これはユーザーのアクセス傾向、集計系クエリ、キャッシュの効いていないエンドポイントなどが原因となることがあります。このようにトラフィックパターンが偏ると、そのキーを保持するリージョンがボトルネックとなります。

これら2つのパターンはいずれも、CPU使用率の急上昇、レイテンシの増加 (特にロングテール)、クラスタ全体のパフォーマンス低下を引き起こす可能性があります。

モニタリングによるTiDBパフォーマンスホットスポットの特定

TiDBにおけるパフォーマンスホットスポットの診断は、まず可視化から始まります。どのノードやクエリに負荷が集中しているのか、そしてその理由を特定する必要があります。TiDB Dashboardは、こうした問題を発見するためのさまざまな手段を提供しており、特にTiKVのCPUメトリクスやTop SQLを通じた分析が有効です。

TiKVのCPUメトリクスでホットノードを特定する

まずは、TiKVノード全体のCPU使用率を確認しましょう：

1. TiDB Dashboardを開き、TiKV CPUのセクションに移動します。
2. 他のノードと比べて、著しくCPU使用率が高いノードを探します。
3. 該当するノードをクリックして詳細を確認します。1つ以上のノードでホットスポットが発生している可能性があります。

上の例では、tikv-2 のCPU使用率が他のノードに比べて非常に高くなっており、これは明らかな警告サインです。

Top SQLデータを分析する

Top SQLは、クラスタに最も負荷をかけているSQLクエリを可視化します。これにより、特定のクエリがホットスポットの原因になっているかどうかを判断しやすくなります。

1. TiDB Dashboardを開き、Top SQLセクションに移動します。
2. CPU使用率の上位に継続的に表示されているクエリを探します。
3. 必要に応じて、クエリの最適化やデータの再分散を検討してください。

TiDB 8.5の新機能：Top SQLはクエリ単位だけでなくテーブル単位での集計が可能になりました。これは、同じテーブルに対して異なる種類のクエリが集中し、結果的にホットスポットを引き起こしているようなケースで特に有効です。

例：クエリ単位またはテーブル単位のホットスポットを特定する

たとえば、特定のSQLクエリが常にCPU使用率の上位に表示されていることに気付いたとします。これは、そのクエリがホットスポットを引き起こしている強い兆候です。そのクエリを最適化するか、クエリがアクセスしているデータの配置を調整することで、クラスタへの負荷を軽減できる可能性があります。

クエリビューだけでは全体像が把握できない場合、TiDB 8.5ではTop SQLにおいてテーブル単位での集計が追加されました。これにより、高いリソース消費と関連するテーブルをより簡単に把握できるようになります。

TiDBパフォーマンスホットスポット：システムテーブルを使ってホットリージョンを特定する

もしTiKV CPUやTop SQLのデータがホットスポットを示しているが、どこでどのように発生しているのかがわからない場合、TiDBのシステムテーブルを使用することで、ホットリージョンを明らかにし、さらに問題を追跡できます。

もしTop SQLが無効化されているか、十分な詳細が表示されない場合、システムテーブルは問題のあるリージョンやワークロードを特定するための別の手段を提供します。

これらのテーブルは以下のような場合に特に役立ちます：

• ノード間で不均衡な負荷が発生しているが、どのクエリが原因か明らかでない。
• 問題のあるテーブルやパーティションを特定するために、リアルタイムまたは過去のホットスポット・データを関連付けたい場合。

主なテーブルを以下に示します：

テーブル名	目的
TIDB_HOT_REGIONS	読み書き量と負荷の度合いを示す、アクティブなホットリージョンを表示
TIDB_HOT_REGIONS_HISTORY	時系列でホットリージョンを追跡し、時間ベースの分析をサポート
TIKV_REGION_PEERS	リージョンをTiKVストアとリーダーにマッピング
TIKV_STORE_STATUS	特定のTiKVノードに関連するストアを関連付けるのに役立つ

例：現在発生しているホットリージョンを特定する

どのリージョンが最もトラフィックを発生させているかを調べるには、次のクエリを使用します：

SELECT h.DB_NAME, h.TABLE_NAME, h.INDEX_NAME, h.REGION_ID,
       s.ADDRESS AS LEADER_ADDRESS, h.TYPE, h.MAX_HOT_DEGREE,
       h.REGION_COUNT, h.FLOW_BYTES
FROM information_schema.TIDB_HOT_REGIONS AS h
JOIN information_schema.TIKV_REGION_PEERS AS p ON h.REGION_ID = p.REGION_ID
JOIN information_schema.TIKV_STORE_STATUS AS s ON p.STORE_ID = s.STORE_ID
WHERE p.IS_LEADER = 1
ORDER BY h.FLOW_BYTES DESC
LIMIT 10;

+-----------------------+------------+------------+-----------+-------------------------------------------------------------+------+----------------+--------------+------------+
| DB_NAME               | TABLE_NAME | INDEX_NAME | REGION_ID | LEADER_ADDRESS                                              | TYPE | MAX_HOT_DEGREE | REGION_COUNT | FLOW_BYTES |
+-----------------------+------------+------------+-----------+-------------------------------------------------------------+------+----------------+--------------+------------+
| rg_sbtest_32_10000000 | sbtest24   | NULL       |      2196 | tc-tikv-2.tc-tikv-peer.csn-resource-control-dd5g6.svc:20160 | read |           2797 |            0 |       8138 |
| rg_sbtest_32_10000000 | sbtest30   | NULL       |       880 | tc-tikv-1.tc-tikv-peer.csn-resource-control-dd5g6.svc:20160 | read |           2831 |            0 |          0 |
| rg_sbtest_32_10000000 | sbtest26   | NULL       |      1548 | tc-tikv-2.tc-tikv-peer.csn-resource-control-dd5g6.svc:20160 | read |            145 |            0 |          0 |
+-----------------------+------------+------------+-----------+-------------------------------------------------------------+------+----------------+--------------+------------+
3 rows in set (0.46 sec)

このクエリは、トラフィック (FLOW_BYTES) による上位10のホットリージョンを表示し、対応するテーブル、インデックス、およびTiKVリーダーノードも示します。

過去のホットスポットを分析する

パフォーマンスの問題は、 高トラフィックのピーク時やバッチジョブ、オフピークの活動時など、特定の期間にのみ現れることがあります。そこで役立つのが、TIDB_HOT_REGIONS_HISTORYテーブルです。このテーブルは、ホットスポットがいつどこで発生したかを特定するのに役立ち、リアルタイムのメトリクスでは見逃す可能性のあるパターンを発見できます。

これは特に以下のような場合に有効です：

• パフォーマンスの低下とトラフィックの急増を関連付ける必要がある場合。
• リアルタイム分析中に発見できない断続的な問題を診断している場合。

例：ピークトラフィック時のホットテーブルを特定する

直近30分間で最もトラフィックが多かったテーブルを特定するには、次のクエリを使用します：

SELECT DB_NAME, TABLE_NAME, AVG(FLOW_BYTES) AS FLOW_BYTES
FROM INFORMATION_SCHEMA.TIDB_HOT_REGIONS_HISTORY
WHERE update_time > DATE_SUB(NOW(), INTERVAL 30 MINUTE)
  AND STORE_ID = "1249"
GROUP BY DB_NAME, TABLE_NAME
ORDER BY FLOW_BYTES DESC
LIMIT 20;

例：オフピーク期間中のホットテーブルを特定する

オフピーク期間を利用して、バックグラウンド負荷や予期しないホットスポットを特定することもできます。これらの負荷がホットスポットを引き起こす場合があります。

SELECT DB_NAME, TABLE_NAME, AVG(QUERY_RATE) AS QUERY_RATE
FROM INFORMATION_SCHEMA.TIDB_HOT_REGIONS_HISTORY
WHERE update_time BETWEEN DATE_SUB(NOW(), INTERVAL 270 MINUTE)
                     AND DATE_SUB(NOW(), INTERVAL 240 MINUTE)
  AND STORE_ID = "1249"
GROUP BY DB_NAME, TABLE_NAME
ORDER BY QUERY_RATE DESC
LIMIT 20;

これらの履歴ビューは、根本原因分析やキャパシティプランニングに非常に有効です。特に、時間を通じた傾向が瞬間的なスナップショットよりも重要となるような、複雑なマルチテナントアーキテクチャではさらに効果を発揮します。

結論

ホットスポットは、分散システムにおける最も一般的で、かつ最も厄介なパフォーマンス問題の原因のひとつです。しかし、適切なツールを使えば、その原因を突き止めるのは決して難しいことではありません。

TiDBは、TiKV CPUメトリクスから、トラフィックが実際にどこにあるかを示すトップSQLやシステムテーブルまで、ホットスポットを明らかにして理解するための複数の方法を提供します。さらに、TiDB 8.5では、トラブルシューティングをより迅速かつ的確に行うためのテーブルレベルのインサイトなど、より深い可視性が得られます。

現在の問題を解決するのは、あくまで出発点にすぎません。次回の記事では、AIエージェントや大規模言語モデル (LLM) を活用し、ホットスポット検出を受動的な対応から能動的な対策へと進化させる方法についてご紹介する予定です。

私たちは常に学びを深め、得た知見を共有しています。ご質問があれば、ぜひTwitter、LinkedIn、またはSlackチャンネルでお気軽にご連絡ください。