TiDB-X-CLOUD.202603.1 リリースノート
リリース日: 2026年7月16日
適用対象の TiDB Cloud プラン: TiDB Cloud Essential および TiDB Cloud Premium
TiDB X カーネルバージョン: TiDB-X-CLOUD.202603.1
2026年7月16日以降、新しく作成される TiDB Cloud Essential および TiDB Cloud Premium インスタンスのデフォルトのカーネルバージョンは TiDB-X-CLOUD.202603.1 です。
TiDB-X-CLOUD.202603.1 では、次のようになります。
202603は、このカーネルバージョンのベースラインコードブランチが 2026年3月に作成されたことを示しており、リリース日とは異なります。1は、TiDB-X-CLOUD.202603ベースラインブランチからビルドされた最初のパッチリリースであることを示します。
機能
パフォーマンス
特定の損失のある DDL 操作（
BIGINT → INTやCHAR(120) → VARCHAR(60)など）に対して大幅なパフォーマンス改善を導入しました。データ切り捨てが発生しない場合、これらの操作の実行時間を数時間から数分、数秒、さらには数ミリ秒まで短縮でき、数十倍から数十万倍の性能向上を実現します #63366 @wjhuang2016 @tangenta @fzzf678最適化戦略は次のとおりです。
- 厳密な SQL モードでは、TiDB は型変換時の潜在的なデータ切り捨てリスクを事前チェックします。
- データ切り捨てリスクが検出されない場合、TiDB はメタデータのみを更新し、可能な限りインデックスの再構築を回避します。
- インデックスの再構築が必要な場合、TiDB はより効率的な取り込みプロセスを使用して、インデックス再構築のパフォーマンスを大幅に向上させます。
次の表は、114 GiB のデータと 6 億行を持つテーブルに対するベンチマークテストに基づく性能改善の例を示しています。テストクラスターは 3 台の TiDB ノード、6 台の TiKV ノード、1 台の PD ノードで構成されています。すべてのノードは 16 CPU コアと 32 GiB のメモリで構成されています。
上記のテスト結果は、DDL 実行中にデータ切り捨てが発生しないことを前提としています。これらの最適化は、符号付き整数型と符号なし整数型の間の変換、文字セット間の変換、または TiFlash レプリカを持つテーブルには適用されません。
詳細は、ドキュメントを参照してください。
可観測性
スロークエリに対して、多次元かつきめ細かなトリガールールの定義をサポートしました #62959 #64010 @zimulala
TiDB Cloud では、デフォルトで 300 ミリ秒を超える SQL クエリがスロークエリと見なされます。スロークエリは、TiDB Cloud コンソールの Diagnosis ページにある Slow Query タブで確認できます。
TiDB Cloud では、スロークエリログの出力をより柔軟に制御できるようになりました。
tidb_slow_log_rulesシステム変数を使用すると、Query_time、Digest、Mem_max、KV_totalなどの条件に基づいて、セッションレベルおよび SQL レベルで多次元のスロークエリログ出力ルールを定義できます。WRITE_SLOW_LOGヒントを使用すると、特定の SQL 文に対してスロークエリログ出力を強制できます。これにより、スロークエリログをより柔軟かつきめ細かく制御できます。詳細は、ドキュメントを参照してください。
SQL
FOR UPDATE OF句でのテーブルエイリアスの使用をサポートしました #63035 @cryo-zdこのリリース以前は、
SELECT ... FOR UPDATE OF <table>文のロック句でテーブルエイリアスを参照すると、TiDB がそのエイリアスを正しく解決できず、エイリアスが有効であってもtable not existsエラーを返すことがありました。TiDB は
FOR UPDATE OF句でのテーブルエイリアスの使用をサポートします。TiDB は、エイリアス付きテーブルを含むFROM句からロック対象を正しく解決できるようになり、行ロックが期待どおりに有効になります。これにより、MySQL 互換性が向上し、テーブルエイリアスを使用するクエリにおけるSELECT ... FOR UPDATE OF文の安定性と信頼性が高まります。詳細は、ドキュメントを参照してください。
インデックスストレージと DML メンテナンスのオーバーヘッドを削減する部分インデックスをサポートしました #62664 #62761 #62758 #63447 #64344 @YangKeao @winoros @wjhuang2016
TiDB は部分インデックスをサポートするようになりました。部分インデックスは、インデックスの
WHERE句で定義された述語を満たす行だけをインデックス化します。部分インデックスは、CREATE INDEX ... WHERE ...、ALTER TABLE ... ADD INDEX ... WHERE ...、またはCREATE TABLE内のインデックス定義を使用して作成できます。部分インデックスは、特定の条件に基づく行のサブセットを頻繁にクエリする場合や、特定の条件下でのみ適用される一意制約が必要な場合に有用です。述語の対象外となる行はインデックスに書き込まれないため、部分インデックスはインデックスストレージの削減に役立ち、
INSERT、UPDATE、DELETE操作時のインデックスメンテナンスのオーバーヘッドも低減できます。部分インデックスを効果的に使用するには、一般的なクエリのフィルターに一致する述語を定義してください。TiDB は、クエリ述語が部分インデックスの述語に一致するか、それを含意する場合にのみ部分インデックスを選択します。現在、部分インデックスの述語では、基本的な比較演算子（
=,!=,<,<=,>,>=）、IS NULL、IS NOT NULL、および定数値を使ったIN述語をサポートしています。詳細は、ドキュメントを参照してください。
互換性の変更
MySQL 互換性
改善
- Parquet ファイルの解析メカニズムを強化し、Parquet 形式データのインポート性能を向上させました #62906 @joechenrh
tidb_analyze_column_optionsのデフォルト値をALLに変更し、デフォルトで全カラムの統計情報を収集するようにしました #64992 @0xPoe- 特定の JOIN シナリオで増分処理を使用することで
IndexHashJoin演算子の実行ロジックを最適化し、一度に大量のデータをロードすることを回避して、メモリ使用量を大幅に削減し、パフォーマンスを向上させました #63303 @ChangRui-Ryan - グローバルシステム変数
tidb_enable_batch_query_regionを追加し、TiDB が PD に対してバッチ化されたリージョン問い合わせを使用するかどうかを制御できるようにしました。これにより、リージョン情報取得の効率が向上します。この変数はデフォルトで無効です #58439 #8690 @JmPotato - コスト見積もりの前に無関係なインデックスをプルーニングすることで、多数のインデックスを持つテーブルに対するクエリのオプティマイザ性能を向上させ、クエリ計画時間を短縮し、不要な全範囲の範囲外見積もりを回避します #63856 @terry1purcell @qw4990
- 一致するプレフィックスインデックス上の
ORDER BY ... LIMIT/OFFSETクエリに対する部分順序付きインデックス最適化をサポートしました。tidb_opt_partial_ordered_index_for_topnをCOSTに設定すると、TiDB はインデックスの部分順序性を利用してフルテーブルスキャンを削減し、TOPNクエリのパフォーマンスを向上できます #63280 #65813 #66338 @elsa0520 @xzhangxian1008 @winoros - ローカルインデックスを持つ高度にパーティション化されたテーブル上の
IndexLookUpクエリにおけるコプロセッサーリクエストのバーストを緩和し、クエリの安定性を向上させ、性能スパイクを低減しました #67545 @gengliqi - 実行中の不要な式バッファ割り当てを削減することで、
INSERT ... ON DUPLICATE KEY UPDATE文の CPU およびメモリ使用量を最適化しました #65003 @windtalker - タイムスタンプ進行および Leader 選出のロジックを最適化しました #9981 @bufferflies