最適なパフォーマンスを得るための TiDB の設定

このガイドでは、TiDB のパフォーマンスを最適化する方法について説明します。

• 一般的なワークロードのベスト プラクティス。
• 困難なパフォーマンス シナリオを処理するための戦略。

注記：

このガイドの最適化手法は、TiDB で最適なパフォーマンスを実現するのに役立ちます。ただし、パフォーマンスのチューニングには複数の要素のバランスを取る必要があることが多く、単一のソリューションですべてのパフォーマンス ニーズに対応できるわけではありません。このガイドの一部の手法では、実験的機能を使用しており、その旨が示されています。これらの最適化によりパフォーマンスが大幅に向上する可能性がありますが、本番環境には適さない可能性があり、実装前に慎重に評価する必要があります。

概要

TiDB を最高のパフォーマンスに最適化するには、さまざまな設定を慎重に調整する必要があります。多くの場合、最適なパフォーマンスを実現するには、デフォルト値を超えて構成を調整する必要があります。

デフォルト設定では、パフォーマンスよりも安定性が優先されます。パフォーマンスを最大化するには、より積極的な構成や、場合によっては実験的機能を使用する必要がある場合があります。これらの推奨事項は、本番の展開経験とパフォーマンス最適化の調査に基づいています。

このガイドでは、デフォルト以外の設定について、その利点や潜在的なトレードオフなどを含めて説明します。この情報を使用して、ワークロード要件に合わせて TiDB 設定を最適化してください。

一般的なワークロードのキー設定

TiDB のパフォーマンスを最適化するために、次の設定が一般的に使用されます。

• SQL 準備実行プラン キャッシュなどの実行プランインスタンスレベルの実行プランキャッシュ 準備されていないプラン キャッシュ強化します。
• オプティマイザー修正コントロール使用して TiDB オプティマイザーの動作を最適化します。
• タイタンstorageエンジンをより積極的に使用します。

これらの設定により、多くのワークロードのパフォーマンスが大幅に向上します。ただし、他の最適化と同様に、本番に展開する前に、ご使用の環境で徹底的にテストしてください。

システム変数

推奨設定を適用するには、次の SQL コマンドを実行します。

SET GLOBAL tidb_enable_instance_plan_cache=on;
SET GLOBAL tidb_instance_plan_cache_max_size=2GiB;
SET GLOBAL tidb_enable_non_prepared_plan_cache=on;
SET GLOBAL tidb_ignore_prepared_cache_close_stmt=on;
SET GLOBAL tidb_enable_inl_join_inner_multi_pattern=on;
SET GLOBAL tidb_opt_derive_topn=on;
SET GLOBAL tidb_runtime_filter_mode=LOCAL;
SET GLOBAL tidb_opt_enable_mpp_shared_cte_execution=on;
SET GLOBAL tidb_rc_read_check_ts=on;
SET GLOBAL tidb_guarantee_linearizability=off;
SET GLOBAL pd_enable_follower_handle_region=on;
SET GLOBAL tidb_opt_fix_control = '44262:ON,44389:ON,44823:10000,44830:ON,44855:ON,52869:ON';

次の表は、特定のシステム変数の構成の影響を示しています。

追加の最適化を可能にするオプティマイザー制御構成について次に説明します。

• 44262:ON : グローバル統計つが欠落している場合は、 動的プルーニングモード使用してパーティションテーブルにアクセスします。
• 44389:ON : c = 10 and (a = 'xx' or (a = 'kk' and b = 1))などのフィルターの場合は、 IndexRangeScanのより包括的なスキャン範囲を構築します。
• 44823:10000 :メモリを節約するために、プラン キャッシュはこの変数で指定された数を超えるパラメータを持つクエリをキャッシュしません。プラン キャッシュ パラメータの制限を200から10000に増やして、長いインリストを持つクエリでプラン キャッシュを使用できるようにします。
• 44830:ON : プラン キャッシュは、物理的な最適化中に生成されたPointGetの演算子を使用して実行プランをキャッシュできます。
• 44855:ON : IndexJoin演算子のProbe側にSelection演算子が含まれている場合、オプティマイザーはIndexJoin選択します。
• 52869:ON : オプティマイザがクエリ プランに対して単一インデックス スキャン メソッド (フル テーブル スキャン以外) を選択できる場合、オプティマイザはインデックス マージを自動的に選択します。

TiDB 構成

TiDB 構成ファイルに次の構成項目を追加します。

[performance]
concurrently-init-stats = true
force-init-stats = true
lite-init-stats = false

TiKV 構成

TiKV 構成ファイルに次の構成項目を追加します。

[server]
concurrent-send-snap-limit = 64
concurrent-recv-snap-limit = 64
snap-io-max-bytes-per-sec = "400MiB"

[pessimistic-txn]
in-memory-peer-size-limit = "32MiB"
in-memory-instance-size-limit = "512MiB"

[rocksdb.titan]
enabled = true
[rocksdb.defaultcf.titan]
min-blob-size = "1KB"
blob-file-compression = "zstd"

[storage.flow-control]
l0-files-threshold = 60

TiFlash構成

TiFlash構成ファイルに次の構成項目を追加します。

[raftstore-proxy.server]
snap-io-max-bytes-per-sec = "300MiB"

ベンチマーク

このセクションでは、デフォルト設定 (ベースライン) と、前述の一般的な負荷のキー設定に基づいて最適化された設定のパフォーマンスを比較します。

1000 個のテーブルでの Sysbench ワークロード

テスト環境

テスト環境は次のとおりです。

• 3 台の TiDB サーバー (16 コア、64 GiB)
• 3 台の TiKV サーバー (16 コア、64 GiB)
• TiDB バージョン: v8.4.0
• 作業量: sysbench oltp_read_only

パフォーマンス比較

次の表は、ベースライン設定と最適化設定の間のスループット、レイテンシー、プラン キャッシュ ヒット率を比較したものです。

主なメリット

インスタンス プラン キャッシュは、ベースライン構成に比べてパフォーマンスが大幅に向上します。

• ヒット率の向上: 53.82% 増加 (56.89% から 87.51%)。

• メモリ使用量の削減: 26.34% 減少 (95.3 MiB から 70.2 MiB)。

• パフォーマンスの向上:

  • QPS は 12.38% 増加します。
  • 平均レイテンシーは 11.01% 減少します。
  • P95レイテンシーは 13.41% 減少します。

仕組み

インスタンス プラン キャッシュは、次のメカニズムを通じてパフォーマンスを向上させます。

• SELECTステートメントの実行プランをメモリにキャッシュします。
• 同じ TiDB インスタンス上のすべての接続 (最大 200) にわたってキャッシュされたプランを共有します。
• 1,000 個のテーブルにわたって最大 5,000 SELECTステートメントのプランを効率的に保存できます。
• キャッシュ ミスは主にBEGINおよびCOMMITステートメントでのみ発生します。

現実世界のメリット

単純な sysbench oltp_read_onlyクエリ (プランあたり 14 KB) を使用したベンチマークではわずかな改善が見られますが、実際のアプリケーションではさらに大きなメリットが期待できます。

• 複雑なクエリは最大 20 倍高速に実行できます。
• セッション レベルのプラン キャッシュと比較して、メモリの使用効率が向上します。

インスタンス プラン キャッシュは、次のようなシステムに特に効果的です。

• 多くの列を持つ大きなテーブル。
• 複雑な SQL クエリ。
• 同時接続数が多い。
• 多様なクエリパターン。

メモリ効率

インスタンス プラン キャッシュは、次の理由により、セッション レベルのプラン キャッシュよりもメモリ効率が優れています。

• プランはすべての接続で共有されます
• 各セッションごとに計画を重複させる必要はありません
• 高いヒット率を維持しながらメモリをより効率的に利用

複数の接続と複雑なクエリがあるシナリオでは、セッション レベルのプラン キャッシュでは同様のヒット率を達成するために大幅に多くのメモリが必要になるため、インスタンス プラン キャッシュの方が効率的な選択肢になります。

テストの作業負荷

次のsysbench oltp_read_only prepareのコマンドはデータをロードします。

sysbench oltp_read_only prepare --mysql-host={host} --mysql-port={port} --mysql-user=root --db-driver=mysql --mysql-db=test --threads=100 --time=900 --report-interval=10 --tables=1000 --table-size=10000

次のsysbench oltp_read_only runのコマンドはワークロードを実行します。

sysbench oltp_read_only run --mysql-host={host} --mysql-port={port} --mysql-user=root --db-driver=mysql --mysql-db=test --threads=200 --time=900 --report-interval=10 --tables=1000 --table-size=10000

詳細についてはSysbench を使用して TiDB をテストする方法参照してください。

大きなレコード値に対するYCSBのワークロード

テスト環境

テスト環境は次のとおりです。

• 3 台の TiDB サーバー (16 コア、64 GiB)
• 3 台の TiKV サーバー (16 コア、64 GiB)
• TiDB バージョン: v8.4.0
• 作業量: go-ycsb ワークロード

パフォーマンス比較

次の表は、ベースライン設定と最適化設定間のスループット (1 秒あたりの操作数) を比較したものです。

パフォーマンス分析

Titan は v7.6.0 以降ではデフォルトで有効になっており、TiDB v8.4.0 の Titan のデフォルトmin-blob-sizeは32KiBです。ベースライン構成では、データが RocksDB に保存されるようにレコード サイズ31KiBを使用します。一方、キー設定構成では、 min-blob-sizeを1KiBに設定して、データが Titan に保存されるようにします。

主要な設定で確認されたパフォーマンスの向上は、主に Titan の RocksDB 圧縮を削減する機能によるものです。次の図に示されています。

• ベースライン: RocksDB 圧縮の合計スループットは 1 GiB/秒を超え、ピーク時には 3 GiB/秒を超えます。
• 主要な設定: RocksDB 圧縮のピーク スループットは 100 MiB/s 未満に維持されます。

この圧縮オーバーヘッドの大幅な削減は、主要な設定構成で確認される全体的なスループットの向上に貢献します。

テストの作業負荷

次のgo-ycsb loadのコマンドはデータをロードします。

go-ycsb load mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p threadcount=100 -p recordcount=5000000 -p operationcount=5000000 -p workload=core -p requestdistribution=uniform -pfieldcount=31 -p fieldlength=1024

次のgo-ycsb runのコマンドはワークロードを実行します。

go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p mysql.db=test -p threadcount=100 -p recordcount=5000000 -p operationcount=5000000 -p workload=core -prequestdistribution=uniform -p fieldcount=31 -p fieldlength=1024

エッジケースと最適化

このセクションでは、基本的な最適化を超えたターゲット調整が必要な特定のシナリオに合わせて TiDB を最適化する方法を説明します。特定のユースケースに合わせて TiDB を調整する方法を学習します。

エッジケースを特定する

エッジケースを識別するには、次の手順を実行します。

1. クエリ パターンとワークロードの特性を分析します。
2. システム メトリックを監視してパフォーマンスのボトルネックを特定します。
3. 特定の問題についてアプリケーション チームからフィードバックを収集します。

よくあるエッジケース

以下に、一般的なエッジ ケースをいくつか示します。

• 頻度の高い小さなクエリに対する TSO 待機時間が長い
• さまざまなワークロードに適した最大チャンクサイズを選択する
• 読み取り負荷の高いワークロード向けにコプロセッサ キャッシュを調整する
• ワークロード特性に合わせてチャンクサイズを最適化する
• さまざまなワークロードに合わせてトランザクション モードと DML タイプを最適化する
• TiKVプッシュダウンでGROUP BYとDISTINCT操作を最適化する
• インメモリエンジンを使用してMVCCバージョンの蓄積を軽減する
• バッチ操作中の統計収集を最適化する
• さまざまなインスタンスタイプに合わせてスレッドプール設定を最適化する

次のセクションでは、それぞれのケースの処理方法について説明します。シナリオごとに異なるパラメータを調整するか、特定の TiDB 機能を使用する必要があります。

注記：

これらの最適化は、ユースケースやデータ パターンによって効果が異なる可能性があるため、慎重に適用し、徹底的にテストしてください。

頻度の高い小さなクエリに対する TSO 待機時間が長い

トラブルシューティング

ワークロードに、タイムスタンプを頻繁に要求する小さなトランザクションやクエリが頻繁に含まれる場合、 TSO (タイムスタンプ オラクル)パフォーマンスのボトルネックになる可能性があります。TSO 待機時間がシステムに影響を与えているかどうかを確認するには、 パフォーマンスの概要 > SQL 実行時間の概要パネルを確認します。TSO 待機時間が SQL 実行時間の大部分を占める場合は、次の最適化を検討してください。

• 厳密な一貫性を必要としない読み取り操作には、低精度 TSO (有効tidb_low_resolution_tso ) を使用します。詳細については、 解決策1: 低精度TSOを使用する参照してください。
• 可能な場合は、小規模なトランザクションを大規模なトランザクションに統合します。詳細については、 ソリューション2: TSOリクエストの並列モード参照してください。

解決策1: 低精度TSO

低精度TSO機能（ tidb_low_resolution_tso ）を有効にすると、TSO待機時間を短縮できます。この機能を有効にすると、TiDBはキャッシュされたタイムスタンプを使用してデータを読み取るため、潜在的に古い読み取りを犠牲にしてTSO待機時間を短縮できます。

この最適化は、次のシナリオで特に効果的です。

• 多少の古さが許容される、読み取り中心のワークロード。
• 絶対的な一貫性よりもクエリのレイテンシーを減らすことの方が重要なシナリオ。
• 最新のコミット状態から数秒遅れた読み取りを許容できるアプリケーション。

利点とトレードオフ:

• キャッシュされた TSO を使用して古い読み取りを有効にすることでクエリのレイテンシーを短縮し、新しいタイムスタンプを要求する必要性を排除します。
• パフォーマンスとデータの一貫性のバランスをとる: この機能は、古い読み取りが許容されるシナリオにのみ適しています。厳密なデータの一貫性が必要な場合には、この機能を使用することはお勧めしません。

この最適化を有効にするには:

SET GLOBAL tidb_low_resolution_tso=ON;

ソリューション2: TSOリクエストの並列モード

tidb_tso_client_rpc_modeシステム変数は、TiDB が TSO RPC 要求を PD に送信するモードを切り替えます。デフォルト値はDEFAULTです。次の条件が満たされる場合は、パフォーマンスの向上の可能性を考慮して、この変数をPARALLELまたはPARALLEL-FASTに切り替えることを検討してください。

• TSO 待機時間は、SQL クエリの合計実行時間の大部分を占めます。
• PD における TSO 割り当てはボトルネックに達していません。
• PD ノードと TiDB ノードには十分な CPU リソースがあります。
• TiDB と PD 間のネットワークレイテンシーは、PD が TSO を割り当てるのにかかる時間よりも大幅に長くなります (つまり、ネットワークレイテンシーがTSO RPC 期間の大部分を占めます)。
  • TSO RPC リクエストの期間を取得するには、Grafana TiDB ダッシュボードの PD クライアント セクションにあるPD TSO RPC 期間パネルを確認します。
  • PD TSO 割り当ての期間を取得するには、Grafana PD ダッシュボードの TiDB セクションにあるPDサーバーTSO ハンドル期間パネルを確認します。
• TiDB と PD 間の TSO RPC 要求の増加 ( PARALLELの場合は 2 回、 PARALLEL-FASTの場合は 4 回) によって生じる追加のネットワーク トラフィックは許容されます。

パラレルモードを切り替えるには、次のコマンドを実行します。

-- Use the PARALLEL mode
SET GLOBAL tidb_tso_client_rpc_mode=PARALLEL;

-- Use the PARALLEL-FAST mode
SET GLOBAL tidb_tso_client_rpc_mode=PARALLEL-FAST;

読み取り負荷の高いワークロード向けにコプロセッサ キャッシュを調整する

コプロセッサキャッシュ最適化することで、読み取り負荷の高いワークロードのクエリ パフォーマンスを向上させることができます。このキャッシュにはコプロセッサ要求の結果が格納され、頻繁にアクセスされるデータの繰り返し計算が削減されます。キャッシュ パフォーマンスを最適化するには、次の手順を実行します。

1. コプロセッサーキャッシュで説明したメトリックを使用してキャッシュヒット率を監視します。
2. キャッシュ サイズを増やすと、より大きなワーキング セットのヒット率が向上します。
3. クエリ パターンに基づいて許可しきい値を調整します。

読み取り負荷の高いワークロードに推奨される設定を以下に示します。

[tikv-client.copr-cache]
capacity-mb = 4096
admission-max-ranges = 5000
admission-max-result-mb = 10
admission-min-process-ms = 0

ワークロード特性に合わせてチャンクサイズを最適化する

tidb_max_chunk_sizeシステム変数は、実行プロセス中のチャンク内の最大行数を設定します。ワークロードに基づいてこの値を調整すると、パフォーマンスが向上します。

• 大規模な同時実行性と小規模なトランザクションを伴う OLTP ワークロードの場合:

  • 128行から256行の間の値を設定します (デフォルト値は1024です)。
  • これにより、メモリ使用量が削減され、制限クエリが高速化されます。
  • 使用例: ポイント クエリ、小範囲スキャン。

  SET GLOBAL tidb_max_chunk_size = 128;
  

• 複雑なクエリと大規模な結果セットを含む OLAP または分析ワークロードの場合:

  • 1024から4096行の間で値を設定します。
  • これにより、大量のデータをスキャンする際のスループットが向上します。
  • 使用例: 集計、大規模テーブルスキャン。

  SET GLOBAL tidb_max_chunk_size = 4096;
  

さまざまなワークロードに合わせてトランザクション モードと DML タイプを最適化する

TiDB は、さまざまなワークロード パターンのパフォーマンスを最適化するために、さまざまなトランザクション モードと DML 実行タイプを提供します。

トランザクションモード

tidb_txn_modeシステム変数を使用してトランザクション モードを設定できます。

• 悲観的なトランザクションモード (デフォルト):

  • 書き込み競合が発生する可能性のある一般的なワークロードに適しています。
  • より強力な一貫性保証を提供します。

  SET SESSION tidb_txn_mode = "pessimistic";
  

• 楽観的トランザクションモード :

  • 書き込み競合が最小限のワークロードに適しています。
  • 複数ステートメントのトランザクションのパフォーマンスが向上します。
  • 例: BEGIN; INSERT...; INSERT...; COMMIT; .

  SET SESSION tidb_txn_mode = "optimistic";
  

DMLタイプ

バージョン 8.0.0 で導入されたtidb_dml_typeシステム変数を使用して、DML ステートメントの実行モードを制御できます。

バルク DML 実行モードを使用するには、 tidb_dml_typeを"bulk"に設定します。このモードでは、競合なしでバルク データのロードが最適化され、大規模な書き込み操作中のメモリ使用量が削減されます。このモードを使用する前に、次の点を確認してください。

• 自動コミットが有効になっています。
• pessimistic-auto-commit構成項目はfalseに設定されています。

SET SESSION tidb_dml_type = "bulk";

TiKV プッシュダウンを使用してGROUP BYおよびDISTINCT操作を最適化する

TiDB は集計操作を TiKV にプッシュダウンして、データ転送と処理のオーバーヘッドを削減します。パフォーマンスの向上は、データの特性によって異なります。

使用シナリオ

• 理想的なシナリオ（高いパフォーマンス向上）:

  • 異なる値がほとんど含まれない列 (NDV が低い)。
  • 頻繁に重複する値を含むデータ。
  • 例: ステータス列、カテゴリ コード、日付部分。

• 理想的でないシナリオ（潜在的なパフォーマンス低下）:

  • ほとんどが一意の値を含む列 (高い NDV)。
  • 一意の識別子またはタイムスタンプ。
  • 例: ユーザー ID、トランザクション ID。

コンフィグレーション

セッションレベルまたはグローバルレベルでプッシュダウンの最適化を有効にします。

-- Enable regular aggregation pushdown
SET GLOBAL tidb_opt_agg_push_down = ON;

-- Enable distinct aggregation pushdown
SET GLOBAL tidb_opt_distinct_agg_push_down = ON;

インメモリエンジンを使用してMVCCバージョンの蓄積を軽減する

MVCC バージョンが多すぎると、特に読み取り/書き込みが多い領域や、ガベージコレクションと圧縮の問題により、パフォーマンスのボトルネックが発生する可能性があります。この問題を軽減するには、v8.5.0 で導入されたインメモリ エンジンを使用できます。これを有効にするには、TiKV 構成ファイルに次の構成を追加します。

注記：

インメモリ エンジンは、過剰な MVCC バージョンの影響を軽減するのに役立ちますが、メモリ使用量が増加する可能性があります。この機能を有効にした後、システムを監視してください。

[in-memory-engine]
enable = true

バッチ操作中の統計収集を最適化する

統計収集を管理することで、クエリの最適化を維持しながらバッチ操作中のパフォーマンスを最適化できます。このセクションでは、このプロセスを効果的に管理する方法について説明します。

auto analyzeを無効にする場合

次のシナリオでは、システム変数tidb_enable_auto_analyzeをOFFに設定することでauto analyzeを無効にすることができます。

• 大規模なデータのインポート中。
• 一括更新操作中。
• 時間に敏感なバッチ処理用。
• 統計収集のタイミングを完全に制御する必要がある場合。

ベストプラクティス

• バッチ操作の前:

  -- Disable auto analyze
  SET GLOBAL tidb_enable_auto_analyze = OFF;
  

• バッチ操作後:

  -- Manually collect statistics
  ANALYZE TABLE your_table;
  
  -- Re-enable auto analyze
  SET GLOBAL tidb_enable_auto_analyze = ON;
  

さまざまなインスタンスタイプに合わせてスレッドプール設定を最適化する

TiKV のパフォーマンスを向上させるには、インスタンスの CPU リソースに基づいてスレッド プールを構成します。次のガイドラインは、これらの設定を最適化するのに役立ちます。

• 8 ～ 16 個のコアを持つインスタンスの場合、通常はデフォルト設定で十分です。

• 32 個以上のコアを持つインスタンスの場合は、リソースの使用率を向上させるためにプール サイズを増やします。次のように設定を調整します。

  [server]
  # Increase gRPC thread pool 
  grpc-concurrency = 10
  
  [raftstore]
  # Optimize for write-intensive workloads
  apply-pool-size = 4
  store-pool-size = 4
  store-io-pool-size = 2