Slow Query機能で遅いクエリを特定し、インデックスで解決する

はじめに

「なぜかアプリケーションが遅い…」

パフォーマンスの問題は、開発者にとって永遠の課題です。推測でインデックスを追加しても、根本原因が違えば効果はありません。重要なのは、データを元にボトルネックを正確に特定することです。

TiDBには、そのための超強力な診断ツールTiDB Dashboardが標準で組み込まれています。

この記事では、TiDB DashboardのSlow Query機能に絞って、実行に時間がかかっているSQLを特定し、インデックスを追加して解決するまでの一連の流れを、ゼロから解説します。

準備：環境構築とテストデータ

1. TiDBクラスタの起動
   まず、tiup playgroundでローカルにTiDBクラスタを起動します。

Shell

tiupが未インストールの場合

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
source ~/.profile

playgroundを起動

tiup playground
起動時に表示される情報の中から、PDのアドレス（例: 127.0.0.1:2379）とTiDBのポート番号（例: 4000）をメモしておきましょう。

2. sysbenchのインストール
   負荷テストとデータ生成のためにsysbenchをインストールします。

# macOSの場合:
brew install sysbench

# Linux (Ubuntu/Debian) の場合
sudo apt-get update && sudo apt-get install -y sysbench

3. テストデータの準備 (sysbench prepare)
   sysbenchを使って、テスト用のデータベースと100万行のデータを持つテーブルを作成します。

# playground起動時に表示されたポート番号(例: 4000)を指定
sysbench oltp_read_write \
  --mysql-host=127.0.0.1 \
  --mysql-port=4000 \
  --mysql-user=root \
  --mysql-db=sbtest \
  --table-size=1000000 \
  --tables=1 \
  prepare

これで、sbtestデータベースにsbtest1というテーブルが作成されました。

ステップ1: 問題の再現（スロークエリの実行）

sbtest1テーブルのpad列は、インデックスが設定されていないランダムな文字列のカラムです。この列をWHERE句で検索することで、意図的に遅いクエリ（フルテーブルスキャン）を発生させます。

MySQLクライアントでTiDBに接続し、以下のクエリを何度か実行してみてください。実行に少し時間がかかることが体感できるはずです。

SELECT id, k FROM sbtest.sbtest1 WHERE pad LIKE '5%';

ステップ2: Slow Query機能での原因特定

ブラウザでhttp://<PDのアドレス>:2379/dashboardにアクセスし、TiDB Dashboardを開きます。

左側メニューから [Slow Query] をクリックします。

先ほど実行したSELECT ... WHERE pad LIKE '5%';のクエリがリストに表示されています。

クエリをクリックして詳細画面を開き、**「Plan」**タブを選択します。

ここで最も重要なのが実行計画です。operator info列にTableFullScanと表示されているのを確認してください。これが低速の根本原因です。これは、インデックスを使わずにテーブルの全データをスキャンしたことを意味します。図書館で、索引を使わずに全ページを一枚一枚めくって目的の単語を探すようなものです。

ステップ3: 解決策（インデックスの追加）

原因がTableFullScanだと特定できたので、解決策はシンプルです。pad列にインデックスを追加します。

CREATE INDEX idx_pad ON sbtest.sbtest1 (pad);

ステップ4: 改善の確認

インデックス作成後、本当にクエリが速くなったかを確認します。

EXPLAIN ANALYZEで実行計画の変化を確認する
もう一度同じクエリを、今度はEXPLAIN ANALYZEを付けて実行します。

EXPLAIN ANALYZE SELECT id, k FROM sbtest.sbtest1 WHERE pad LIKE '5%';

実行計画がTableFullScanからIndexRangeScanやIndexLookUpに変わっていることを確認してください。これは、インデックスが正しく使われた証拠です。実行時間もミリ秒単位に劇的に改善されているはずです。

Dashboardで確認する
しばらく待ってからTiDB Dashboardの**[Slow Query]**ページを更新すると、先ほどのクエリが表示されなくなっているはずです。これは、クエリが高速化され、スロークエリの閾値（デフォルト300ms）を下回ったことを意味します。

まとめ

パフォーマンスチューニングの第一歩は、推測ではなく計測です。TiDB DashboardのSlow Query機能を使えば、実行に時間がかかっているボトルネックSQLを簡単かつ正確に特定できます。

そして、実行計画を見てTableFullScanを見つけたら、インデックスの追加を検討する。このサイクルを回すことで、データベースのパフォーマンスを継続的に改善していくことができます。ぜひ、お手元の環境でこの強力な診断ツールを試してみてください！