TiDB 7.0.0 リリースノート

発売日：2023年3月30日

TiDB バージョン: 7.0.0- DMR

クイックアクセス: クイックスタート

バージョン7.0.0-DMRの主な新機能と改善点は以下のとおりです。

機能の詳細

拡張性

• TiFlashは、分散storageとコンピューティングアーキテクチャをサポートし、このアーキテクチャにおけるオブジェクトstorageをサポートします（実験的） #6882 @flowbehappy

  バージョン7.0.0より前のTiFlashは、storageとコンピューティングが結合されたアーキテクチャのみをサポートしていました。このアーキテクチャでは、各TiFlashノードがstorageとコンピューティングノードの両方の役割を担い、コンピューティング機能とstorage機能を個別に拡張することはできませんでした。また、 TiFlashノードはローカルstorageしか使用できませんでした。

  バージョン7.0.0以降、 TiFlashは分離型storageおよびコンピューティングアーキテクチャもサポートしています。このアーキテクチャでは、 TiFlashノードは2種類（コンピューティングノードと書き込みノード）に分かれており、S3 APIと互換性のあるオブジェクトstorageをサポートしています。どちらのタイプのノードも、コンピューティング容量またはstorage容量に合わせて個別にスケーリングできます。分離型storageおよびコンピューティングアーキテクチャと結合型storageおよびコンピューティングアーキテクチャは、同じクラスタ内で使用したり、相互に変換したりすることはできません。TiFlashをデプロイする際に、使用するアーキテクチャを設定できます。

  詳細については、ドキュメントを参照してください。

パフォーマンス

• Fast Online DDL と PITR 間の互換性を達成 #38045 @Leavrth

  TiDB v6.5.0では、 高速オンラインDDL PITRと完全には互換性がありません。完全なデータバックアップを確実に行うには、まずPITRのバックグラウンドバックアップタスクを停止し、高速オンラインDDLを使用してインデックスをすばやく追加してから、PITRのバックアップタスクを再開することをお勧めします。

  TiDB v7.0.0以降、Fast Online DDLとPITRは完全に互換性があります。PITRを使用してクラスタデータを復元する場合、ログバックアップ中にFast Online DDLで追加されたインデックス操作が自動的に再生され、互換性が確保されます。

  詳細については、ドキュメントを参照してください。

• TiFlashは、null対応セミジョイン演算子とnull対応アンチセミジョイン演算子をサポートしています #6674 @gengliqi

  相関サブクエリでIN 、 NOT IN 、 = ANY 、または!= ALL演算子を使用する場合、TiDB はそれらを準演算子に変換することでコンピューティング パフォーマンスを最適化します。ジョインまたはアンチセミジョイン。結合キー列がNULLの場合は、 NULL値対応セミジョインやヌル値対応アンチセミジョインなどの、null 対応結合アルゴリズムが必要です。

  バージョン 7.0.0 より前のTiFlashでは、NULL 対応セミ結合演算子と NULL 対応アンチセミ結合演算子がサポートされていなかったため、これらのサブクエリをTiFlashに直接プッシュダウンすることができませんでした。バージョン 7.0.0 以降では、 TiFlash はNULL 対応セミ結合演算子と NULL 対応アンチセミ結合演算子をサポートしています。SQL ステートメントにこれらの相関サブクエリが含まれており、クエリ内のテーブルにTiFlashレプリカがあり、かつMPPモードが有効になっている場合、オプティマイザは全体的なパフォーマンスを向上させるために、NULL 対応セミ結合演算子と NULL 対応アンチセミ結合演算子をTiFlashにプッシュダウンするかどうかを自動的に判断します。

  詳細については、 ドキュメントを参照してください。

• TiFlash はFastScan (GA) #5252 @hongyunyanの使用をサポートしています

  TiFlash はv6.3.0 から FastScan を実験的機能として導入しました。v7.0.0 では、この機能が一般利用可能になります。FastScan はシステム変数tiflash_fastscanを使用して有効にできます。この機能は、強力な一貫性を犠牲にすることで、テーブルスキャンのパフォーマンスを大幅に向上させます。対応するテーブルがINSERT / { UPDATE操作を含まず、 DELETE操作のみを含む場合、FastScan は強力な一貫性を維持し、スキャンのパフォーマンスを向上させることができます。

  詳細については、ドキュメントを参照してください。

• TiFlashは後期実体化をサポート (実験的) #5829 @Lloyd-Pottiger

  フィルタ条件 ( SELECT WHEREステートメントを処理する場合、 TiFlash はデフォルトでクエリに必要な列からすべてのデータを読み取り、クエリ条件に基づいてデータをフィルタリングおよび集計します。遅延マテリアライゼーションは、フィルタ条件の一部を TableScan オペレータにプッシュダウンすることをサポートする最適化手法です。つまり、 TiFlash はまずプッシュダウンされたフィルタ条件に関連する列データをスキャンし、条件を満たす行をフィルタリングしてから、これらの行の他の列データをスキャンしてさらに計算を行うことで、データ処理の IO スキャンと計算を削減します。

  TiFlashの遅延マテリアライゼーション機能は、デフォルトでは有効になっていません。 tidb_opt_enable_late_materializationシステム変数をOFFに設定することで有効にできます。この機能が有効になると、TiDBオプティマイザは統計情報とフィルタ条件に基づいて、どのフィルタ条件をプッシュダウンするかを決定します。

  詳細については、ドキュメントを参照してください。

• 準備されていないステートメントの実行プランのキャッシュをサポートする（実験的） #36598 @qw4990

  実行プラン キャッシュは同時 OLTP の負荷容量を向上させるために重要であり、TiDB はすでに準備された実行プランキャッシュキャッシュをサポートしています。 v7.0.0 では、TiDB は非 Prepare ステートメントの実行プランをキャッシュすることもできるため、実行プラン キャッシュの範囲が拡張され、TiDB の同時処理能力が向上します。

  この機能はデフォルトでは無効になっています。システム変数tidb_enable_non_prepared_plan_cache ONに設定することで有効にできます。安定性のため、TiDB v7.0.0 では準備されていない実行プランをキャッシュするための新しい領域が割り当てられ、システム変数tidb_non_prepared_plan_cache_sizeを使用してキャッシュサイズを設定できます。さらに、この機能には SQL ステートメントに関する特定の制限があります。詳細については、 制限参照してください。

  詳細については、ドキュメントを参照してください。

• TiDB がサブクエリの実行プラン キャッシュ制約を削除 #40219 @fzzf678

  TiDB v7.0.0 では、サブクエリに対する実行プランキャッシュの制約が解除されました。これにより、 SELECT * FROM t WHERE a > (SELECT ...)のようにサブクエリを含む SQL ステートメントの実行プランをキャッシュできるようになりました。この機能により、実行プランキャッシュの適用範囲がさらに拡大し、SQL クエリの実行効率が向上します。

  詳細については、ドキュメントを参照してください。

• TiKVはログリサイクル用の空のログファイルの自動生成をサポートしています #14371 @LykxSassinator

  バージョン6.3.0では、書き込み負荷によって発生するロングテールレイテンシーを低減するために、TiKVはRaftのリサイクル機能を導入しました。しかし、ログのリサイクルはRaftログファイルの数が一定のしきい値に達した場合にのみ有効になるため、ユーザーがこの機能によるスループットの向上を直接体感することは困難です。

  バージョン7.0.0では、ユーザーエクスペリエンスを向上させるためにraft-engine.prefill-for-recycleという新しい設定項目が導入されました。この項目は、プロセスの開始時に空のログファイルが生成されて再利用されるかどうかを制御します。この設定を有効にすると、TiKVは初期化中に空のログファイルのバッチを自動的に作成し、初期化直後にログの再利用が確実に実行されるようにします。

  詳細については、 ドキュメントを参照してください。

• ウィンドウウィンドウ関数からの TopN または Limit 演算子の導出をサポート #13936 @windtalker

  この機能はデフォルトでは無効になっています。有効にするには、セッション変数tidb_opt_derive_topn ONに設定してください。

  詳細については、ドキュメントを参照してください。

• Fast Online DDL によるユニークインデックス作成のサポート #40730 @tangenta

  TiDB v6.5.0 では、Fast Online DDL による通常のセカンダリ インデックスの作成がサポートされています。TiDB v7.0.0 では、Fast Online DDL によるユニーク インデックスの作成がサポートされています。v6.1.0 と比較して、大規模テーブルへのユニーク インデックスの追加は、パフォーマンスの向上により数倍高速化されることが期待されます。

  詳細については、ドキュメントを参照してください。

信頼性

• リソース制御機能の強化 (実験的) #38825 @nolouch@BornChanger@glorv@tiancaiamao@Connor1996 @JmPotato @hnes @CabinfeverB @HuSharp

  TiDBは、リソースグループに基づくリソース制御機能を強化しました。この機能により、TiDBクラスタのリソース利用効率とパフォーマンスが大幅に向上します。リソース制御機能の導入は、TiDBにとって画期的な出来事です。分散データベースクラスタを複数の論理ユニットに分割し、異なるデータベースユーザーを対応するリソースグループにマッピングし、必要に応じて各リソースグループのクォータを設定できます。クラスタのリソースが制限されている場合、同じリソースグループ内のセッションが使用するすべてのリソースはクォータに制限されます。このようにして、リソースグループが過剰に消費された場合でも、他のリソースグループのセッションには影響しません。

  この機能により、異なるシステム上の複数の中小規模アプリケーションを単一のTiDBクラスタに統合できます。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合は、負荷の高いアプリケーションが設定されたクォータを超えても、必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。さらに、リソース制御機能を合理的に活用することで、クラスタ数を削減し、運用保守の負担を軽減し、管理コストを削減できます。

  この機能は、Grafanaにおけるリソースの実際の使用状況を表示する組み込みのリソース制御ダッシュボードを提供し、リソースをより合理的に割り当てるのに役立ちます。また、セッションレベルとステートメントレベルの両方に基づいた動的なリソース管理機能もサポートしています（ヒント）。この機能の導入により、TiDBクラスタのリソース使用状況をより正確に制御し、実際のニーズに基づいてクォータを動的に調整できるようになります。

  TiDB v7.0.0では、リソースグループの絶対スケジューリング優先度（ PRIORITY ）を設定することで、重要なサービスが確実にリソースを取得できるようになります。また、リソースグループの設定方法も拡張されています。

  リソースグループは、以下の方法で使用できます。

  • ユーザーレベル。CREATE CREATE USERまたはALTER USERステートメントを使用して、ユーザーを特定のリソースグループにバインドします。リソースグループをユーザーにバインドすると、そのユーザーが新しく作成したセッションは、対応するリソースグループに自動的にバインドされます。
  • セッションレベル。SET SET RESOURCE GROUPを使用して、現在のセッションで使用されるリソースグループを設定します。
  • ステートメントレベル。RESOURCE_GROUP RESOURCE_GROUP()を使用して、現在のステートメントで使用されるリソースグループを設定します。

  詳細については、ドキュメントを参照してください。

• 高速オンラインDDLのチェックポイントメカニズムをサポートし、耐障害性と自動リカバリ機能を向上させる #42164 @tangenta

  TiDB v7.0.0では、 高速オンラインDDLにチェックポイント機構が導入され、耐障害性と自動リカバリ機能が大幅に向上しました。DDLの進行状況を定期的に記録・同期することで、TiDB DDLオーナーの障害や切り替えが発生した場合でも、進行中のDDL操作を高速オンラインDDLモードで継続実行できます。これにより、DDLの実行がより安定し、効率的になります。

  詳細については、ドキュメントを参照してください。

• TiFlashはディスクへのスピルをサポート #6528 @windtalker

  実行パフォーマンスを向上させるため、 TiFlashは可能な限りデータをメモリ内で処理します。データ量がメモリの総容量を超えると、メモリ不足によるシステムクラッシュを回避するため、 TiFlashはクエリを終了します。したがって、 TiFlashが処理できるデータ量は、利用可能なメモリ容量によって制限されます。

  バージョン7.0.0以降、 TiFlashはディスクへのスピルをサポートしています。オペレータのメモリ使用量のしきい値（ tidb_max_bytes_before_tiflash_external_group_by 、 tidb_max_bytes_before_tiflash_external_sort 、 tidb_max_bytes_before_tiflash_external_join ）を調整することで、オペレータが使用できる最大メモリ量を制御できます。オペレータが使用するメモリがしきい値を超えると、データは自動的にディスクに書き込まれます。これによりパフォーマンスは多少低下しますが、より多くのデータを処理できるようになります。

  詳細については、ドキュメントを参照してください。

• 統計情報の収集効率を向上させる #41930 @xuyifangreeneyes

  バージョン7.0.0では、TiDBは統計情報の収集ロジックをさらに最適化し、収集時間を約25%短縮しました。この最適化により、大規模データベースクラスタの運用効率と安定性が向上し、統計情報の収集がクラスタのパフォーマンスに与える影響が軽減されます。

• MPP 最適化のための新しいオプティマイザー ヒントを追加 #39710 @Reminiscent

  バージョン7.0.0では、TiDBはMPP実行プランの生成に影響を与える一連のオプティマイザヒントを追加しました。

  • SHUFFLE_JOIN() : MPP で有効になります。指定されたテーブルに対してシャッフル結合アルゴリズムを使用するようにオプティマイザに指示します。
  • BROADCAST_JOIN() : MPP で有効になります。指定されたテーブルに対してブロードキャスト結合アルゴリズムを使用するようにオプティマイザに指示します。
  • MPP_1PHASE_AGG() ：MPP（最大パフォーマンス）に有効です。指定されたクエリブロック内のすべての集計関数に対して、オプティマイザに1フェーズ集計アルゴリズムを使用するように指示します。
  • MPP_2PHASE_AGG() : MPP で有効になります。指定されたクエリ ブロック内のすべての集計関数に対して、2 段階集計アルゴリズムを使用するようにオプティマイザに指示します。

  MPPオプティマイザのヒントを使用すると、HTAPクエリに介入して、HTAPワークロードのパフォーマンスと安定性を向上させることができます。

  詳細については、ドキュメントを参照してください。

• オプティマイザーのヒントは、結合メソッドと結合順序の指定をサポートします #36600 @Reminiscent

  バージョン7.0.0では、オプティマイザヒントLEADING()結合方法に影響を与えるヒントと併用できるようになり、両者の動作は互換性があります。複数テーブル結合の場合、最適な結合方法と結合順序を効果的に指定できるため、実行プランに対するオプティマイザヒントの制御が強化されます。

  新しいヒント動作には、若干の変更があります。前方互換性を確保するため、TiDB はシステム変数tidb_opt_advanced_join_hintを導入します。この変数がOFFに設定されている場合、オプティマイザのヒント動作は以前のバージョンと互換性があります。クラスタを以前のバージョンから v7.0.0 以降のバージョンにアップグレードすると、この変数はOFFに設定されます。より柔軟なヒント動作を実現するには、動作によってパフォーマンスが低下しないことを確認した後、この変数をONに設定することを強くお勧めします。

  詳細については、ドキュメントを参照してください。

可用性

• prefer-leaderオプションをサポートします。このオプションは、読み取り操作の可用性を高め、不安定なネットワーク状況での応答レイテンシーを低減します。 #40905 @LykxSassinator

  TiDB のデータ読み取り動作は、システム変数tidb_replica_readで制御できます。v7.0.0 では、この変数にprefer-leaderオプションが追加されました。この変数をprefer-leaderに設定すると、TiDB はリーダー レプリカを選択して読み取り操作を実行することを優先します。ディスクやネットワークのパフォーマンス変動などによりリーダー レプリカの処理速度が著しく低下した場合、TiDB は利用可能な他のフォロワー レプリカを選択して読み取り操作を実行し、可用性を高め、応答レイテンシーを削減します。

  詳細については、ドキュメントを参照してください。

SQL

• Time to Live (TTL) は一般に利用可能です #39262 @lcwangchao @YangKeao

  TTLは行レベルのライフサイクル制御ポリシーを提供します。TiDBでは、TTL属性が設定されたテーブルは、設定に基づいて期限切れの行データを自動的にチェックして削除します。TTLの目的は、クラスタのワークロードへの影響を最小限に抑えながら、ユーザーが不要なデータを定期的に適切なタイミングでクリーンアップできるようにすることです。

  詳細については、ドキュメントを参照してください。

• サポートALTER TABLE…REORGANIZE PARTITION #15000 @mjonss

  TiDBはALTER TABLE...REORGANIZE PARTITION構文をサポートしています。この構文を使用すると、データの損失なしに、テーブルのパーティションの一部または全部を再編成（マージ、分割、その他の変更を含む）できます。

  詳細については、ドキュメントを参照してください。

• キー分割をサポート #41364 @TonsnakeLin

  TiDBはキーパーティショニングをサポートするようになりました。キーパーティショニングとハッシュパーティショニングはどちらも、データを一定数のパーティションに均等に分散できます。違いは、ハッシュパーティショニングは指定された整数式または整数列に基づいてのみデータを分散できるのに対し、キーパーティショニングは列リストに基づいてデータを分散できる点です。また、キーパーティショニングのパーティション列は整数型に限定されません。

  詳細については、ドキュメントを参照してください。

データベース操作

• TiCDC はstorageサービスへの変更データのレプリケーションをサポート (GA) #6797 @zhaoxinyu

  TiCDCは、変更されたデータをAmazon S3、GCS、Azure Blob Storage、NFS、およびその他のS3互換storageサービスに複製することをサポートしています。ストレージサービスは手頃な価格で使いやすく、Kafkaを使用していない場合は、storageサービスを利用できます。TiCDCは変更ログをファイルに保存し、それをstorageサービスに送信します。storageサービスから、独自のコンシューマープログラムが新しく生成された変更ログファイルを定期的に読み取ることができます。現在、TiCDCはcanal-jsonおよびCSV形式の変更ログをstorageサービスに複製することをサポートしています。

  詳細については、ドキュメントを参照してください。

• TiCDC OpenAPI v2 #8019 @sdojjy

  TiCDCはOpenAPI v2を提供します。OpenAPI v1と比較して、OpenAPI v2はレプリケーションタスクをより包括的にサポートします。TiCDC OpenAPIが提供する機能は、 cdc cliツールの機能の一部です。OpenAPI v2を介してTiCDCクラスタを照会および操作できます。例えば、TiCDCノードの状態取得、クラスタの健全性状態の確認、レプリケーションタスクの管理などが可能です。

  詳細については、ドキュメントを参照してください。

• DBeaver v23.0.1 はデフォルトで TiDB をサポートします #17396 @Icemap

  • 独立したTiDBモジュール、アイコン、およびロゴを提供します。
  • デフォルト設定ではTiDB Cloud Starterがサポートされているため、 TiDB Cloud Starterへの接続が容易になります。
  • TiDBのバージョンを識別して、外部キーのタブを表示または非表示にする機能をサポートしています。
  • EXPLAIN結果に SQL 実行プランを視覚化することをサポートします。
  • PESSIMISTIC 、 OPTIMISTIC 、 AUTO_RANDOM 、 PLACEMENT 、 {{B-PLACEHOLDER POLICY 、 REORGANIZE 、 EXCHANGE 、 CACHE NONCLUSTERED } 、 CLUSTEREDなどの TiDB キーワードの強調表示をサポートします。
  • TIDB_BOUNDED_STALENESS 、 TIDB_DECODE_KEY 、 TIDB_DECODE_PLAN 、 TIDB_IS_DDL_OWNER 、{{B-PLACEHOLDER TIDB_PARSE_TSO 、 TIDB_VERSION TIDB_DECODE_SQL_DIGESTS }}、 TIDB_SHARDなどのTiDB関数の強調表示をサポートします。

  詳細については、 DBeaverのドキュメントを参照してください。

データ移行

• LOAD DATAステートメントの機能を強化し、クラウドstorageからのデータインポートをサポートする (実験的) #40499 @lance6716

  TiDB v7.0.0 より前は、 LOAD DATAステートメントではクライアント側からのデータ ファイルのインポートしかできませんでした。クラウドstorageからデータをインポートするには、 TiDB Lightningを使用する必要がありました。しかし、 TiDB Lightning を別途デプロイすると、追加のデプロイおよび管理コストが発生します。v7.0.0 では、 LOAD DATAステートメントを使用してクラウドstorageから直接データをインポートできます。この機能の例を以下に示します。

  • Amazon S3およびGoogle Cloud StorageからTiDBへのデータインポートをサポートします。ワイルドカードを使用して、複数のソースファイルを一度にTiDBにインポートすることをサポートします。
  • DEFINED NULL BYを使用して null を定義することをサポートします。
  • CSVおよびTSV形式のソースファイルをサポートします。

  詳細については、 ドキュメントを参照してください。

• TiDB Lightning は、キーと値のペアを TiKV (GA) に送信する際の圧縮転送の有効化をサポートします #41163 @sleepymole

  バージョン6.6.0以降、 TiDB Lightningは、ローカルでエンコードおよびソートされたキーと値のペアをTiKVに送信する際に圧縮してネットワーク転送する機能をサポートしており、ネットワーク経由で転送されるデータ量を削減し、ネットワーク帯域幅のオーバーヘッドを低減します。この機能がサポートされる以前のTiDBバージョンでは、 TiDB Lightningは比較的高いネットワーク帯域幅を必要とし、データ量が多い場合には高額なトラフィック料金が発生していました。

  バージョン7.0.0では、この機能は一般提供（GA）となり、デフォルトでは無効になっています。有効にするには、 TiDB Lightningの設定項目compress-kv-pairsを"gzip"または"gz" 。

  詳細については、 ドキュメントを参照してください。

互換性の変更

注記：

このセクションでは、バージョン6.6.0から最新バージョン（バージョン7.0.0）にアップグレードする際に知っておくべき互換性の変更点について説明します。バージョン6.5.0以前のバージョンから最新バージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更点も確認する必要があるかもしれません。

MySQLとの互換性

• TiDBは、自動インクリメント列がインデックスでなければならないという制約を削除します #40580 @tiancaiamao

  バージョン 7.0.0 より前は、TiDB の動作は MySQL と一貫しており、自動インクリメント列はインデックスまたはインデックスプレフィックスである必要がありました。バージョン 7.0.0 以降、TiDB は自動インクリメント列がインデックスまたはインデックスプレフィックスである必要があるという制約を撤廃しました。これにより、テーブルの主キーをより柔軟に定義し、自動インクリメント列を使用してソートやページネーションをより簡単に実装できるようになりました。また、自動インクリメント列によって引き起こされる書き込みホットスポットの問題も回避され、クラスタ化インデックスを持つテーブルを使用することでクエリのパフォーマンスが向上します。新しいリリースでは、次の構文を使用してテーブルを作成できます。

  CREATE TABLE test1 (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `k` int(11) NOT NULL DEFAULT '0',
      `c` char(120) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
      PRIMARY KEY(`k`, `id`)
  );
  

  この機能はTiCDCのデータレプリケーションには影響しません。

  詳細については、 ドキュメントを参照してください。

• TiDBは、次の例に示すように、キーパーティションをサポートしています。

  CREATE TABLE employees (
  id INT NOT NULL,
  fname VARCHAR(30),
  lname VARCHAR(30),
  hired DATE NOT NULL DEFAULT '1970-01-01',
  separated DATE DEFAULT '9999-12-31',
  job_code INT,
  store_id INT) PARTITION BY KEY(store_id) PARTITIONS 4;
  

  バージョン7.0.0以降、TiDBはキーパーティションをサポートし、MySQLのPARTITION BY LINEAR KEY構文を解析できます。ただし、TiDBはLINEARキーワードを無視し、代わりに非線形ハッシュアルゴリズムを使用します。現在、 KEYパーティションタイプは、空のパーティション列リストを持つパーティションステートメントをサポートしていません。

  詳細については、ドキュメントを参照してください。

行動の変化

• TiCDC は、Avro #8490 @3AceShowHandのFLOATデータの不正なエンコードの問題を修正しました

  TiCDC クラスターを v7.0.0 にアップグレードする際、Avro を使用してレプリケートされたテーブルにFLOATデータ型が含まれている場合は、アップグレード前に Confluent Schema Registry の互換性ポリシーをNoneに手動で調整する必要があります。そうしないと、changefeed がスキーマを正常に更新できなくなります。そうしないと、アップグレード後に changefeed がスキーマを更新できず、エラー状態になります。

• v7.0.0 以降、 tidb_dml_batch_sizeシステム変数はLOAD DATAステートメントに影響しなくなりました。

システム変数

コンフィグレーションファイルパラメータ

改善点

• TiDB

  • EXPAND演算子を導入し、単一のDISTINCTステートメントに複数のSELECTを含むSQLクエリのパフォーマンスを最適化します #16581 @AilinKid
  • インデックス結合でより多くのSQL形式をサポートする #40505 @Yisaer
  • 場合によっては、TiDB でパーティションテーブルデータをグローバルに並べ替えないようにする #26166 @Defined2014
  • fair lock modeとlock only if existsの同時使用をサポート #42068 @MyonKeminta
  • トランザクションのスローログとトランザクション内部イベントの印刷をサポートする #41863 @ekexium
  • ILIKEオペレーター #40943 @xzhangxian1008をサポートします

• PD

  • ストア制限によるスケジューリング失敗に関する新しい監視メトリックを追加 #6043 @nolouch

• TiFlash

  • 書き込みパスでの TiFlash のメモリ使用量を削減 #7144 @hongyunyan
  • テーブルが多いシナリオでの TiFlash の再起動時間を短縮する #7146 @hongyunyan
  • ILIKEオペレーターのプッシュダウンをサポートします #6740 @xzhangxian1008

• ツール

  • TiCDC

    • Kafkaがダウンストリームとなるシナリオにおいて、単一の大規模テーブルのデータ変更を複数のTiCDCノードに分散することをサポートし、大規模TiDBクラスタのデータ統合シナリオにおける単一テーブルのスケーラビリティ問題を解決します #8247 @overvenus

      TiCDC 構成項目enable_table_across_nodesをtrueに設定することで、この機能を有効にできます。 region_thresholdを使用すると、テーブルのリージョン数がこのしきい値を超えた場合に、TiCDC が対応するテーブルのデータ変更を複数の TiCDC ノードに分散するように指定できます。

    • リドゥアプラにおけるトランザクション分割をサポートし、スループットを向上させ、ディザスタリカバリシナリオにおけるRTOを短縮する #8318 @CharlesCheung96

    • テーブルのスケジューリングを改善して、単一のテーブルをさまざまな TiCDC ノード間でより均等に分割します #8247 @overvenus

    • MQ シンク #8286 @Rustin170506に Large Row モニタリング メトリクスを追加します

    • リージョンに複数のテーブルのデータが含まれるシナリオで、TiKV ノードと TiCDC ノード間のネットワーク トラフィックを削減します #6346 @overvenus

    • Checkpoint TSとResolved TSのP99メトリクスパネルをラグ分析パネルに移動します #8524 @Rustin170506

    • リドゥログへのDDLイベントの適用をサポートする #8361 @CharlesCheung96

    • アップストリーム書き込みスループットに基づいて TiCDC ノードへのテーブルの分割とスケジュールをサポート #7720 @overvenus

  • TiDB Lightning

    • TiDB Lightning物理インポート モードは、データ インポートとインデックス インポートの分離をサポートし、インポート速度と安定性を向上させます #42132 @sleepymole

      add-index-by-sqlパラメータを追加します。デフォルト値はfalseで、これはTiDB Lightning が行データとインデックスデータの両方を KV ペアにエンコードし、それらをまとめて TiKV にインポートすることを意味します。これをtrueに設定すると、 TiDB Lightningデータのインポート後にADD INDEX SQL ステートメントを使用してインデックスを追加し、インポートの速度と安定性を向上させます。

    • tikv-importer.keyspace-nameパラメータを追加します。デフォルト値は空の文字列で、 TiDB Lightning は対応するテナントのキースペース名を自動的に取得してデータをインポートします。値を指定すると、指定されたキースペース名を使用してデータがインポートされます。このパラメータにより、マルチテナント TiDB クラスタにデータをインポートする際のTiDB Lightningの設定に柔軟性が生まれます。 #41915 @lichunzhu

バグ修正

• TiDB

  • TiDBをv6.5.1からそれ以降のバージョンにアップグレードする際にアップデートが欠落する問題を修正 #41502 @chrysan
  • アップグレード後に一部のシステム変数のデフォルト値が変更されない問題を修正 #41423 @crazycs520
  • インデックス追加に関連するコプロセッサー要求タイプが不明として表示される問題を修正 #41400 @tangenta
  • インデックスを追加する際に「PessimisticLockNotFound」が返される問題を修正 #41515 @tangenta
  • 一意のインデックスを追加する際に誤ってfound duplicate keyを返す問題を修正 #41630 @tangenta
  • インデックス追加時のpanic問題を修正 #41880 @tangenta
  • TiFlashが実行中に生成された列に対してエラーを報告する問題を修正 #40663 @guo-shaoge
  • TiDBが時間型の場合に統計情報を正しく取得できない可能性がある問題を修正しました #41938 @xuyifangreeneyes
  • 準備済みプランキャッシュが有効になっている場合に、フルインデックススキャンでエラーが発生する可能性がある問題を修正しました #42150 @fzzf678
  • IFNULL(NOT NULL COLUMN, ...)が間違った結果を返す可能性がある問題を修正 #41734 @LittleFall
  • パーティションテーブル内のすべてのデータが単一のリージョンにある場合に、TiDBが誤った結果を生成する可能性がある問題を修正します #41801 @Defined2014
  • TiDB で、異なるパーティション テーブルが単一の SQL ステートメントに現れる場合に誤った結果が生成される可能性がある問題を修正しました #42135 @mjonss
  • パーティションテーブルに新しいインデックスを追加した後、パーティションパーティションテーブルで統計情報の自動収集が正しくトリガーされない可能性がある問題を修正しました #41638 @xuyifangreeneyes
  • TiDBが統計情報を2回連続で収集した後に誤った列統計情報を読み取る可能性がある問題を修正 #42073 @xuyifangreeneyes
  • プラン準備キャッシュが有効になっている場合に IndexMerge が誤った結果を生成する可能性がある問題を修正しました #41828 @qw4990
  • IndexMerge に goroutine リークがある可能性がある問題を修正 #41605 @guo-shaoge
  • 非 BIGINT 符号なし整数が文字列/10 進数と比較したときに誤った結果を生成する可能性がある問題を修正 #41736 @LittleFall
  • メモリ制限超過により以前のANALYZEステートメントが強制終了されると、同じセッション内の現在のANALYZEステートメントも強制終了される可能性がある問題を修正しました #41825 @XuHuaiyu
  • バッチコプロセッサの情報収集プロセス中にデータ競合が発生する可能性がある問題を修正しました #41412 @you06
  • アサーション エラーによりパーティション テーブルの MVCC 情報が印刷できない問題を修正 #40629 @ekexium
  • フェアロックモードで存在しないキーにロックが追加される問題を修正 #41527 @ekexium
  • INSERT IGNOREおよびREPLACEステートメントが値を変更しないキーをロックしない問題を修正 #42121 @zyguan

• PD

  • リージョンスキャッター操作でリーダーの分布が不均一になる可能性がある問題を修正 #6017 @HunDunDM
  • 起動時にPDメンバーを取得する際にデータ競合が発生する可能性がある問題を修正 #6069 @rleungx
  • ホットスポット統計情報の収集時にデータ競合が発生する可能性がある問題を修正 #6069 @lhy1024
  • 配置ルールの切り替えによりリーダーの分布が不均一になる可能性がある問題を修正 #6195 @bufferflies

• TiFlash

  • 特定の場合に小数の除算で最後の桁が切り上げられない問題を修正 #7022 @LittleFall
  • 特定のケースで Decimal キャストが誤って切り上げられる問題を修正 #6994 @windtalker
  • 新しい照合順序を有効にした後、TopN/Sort演算子が誤った結果を生成する問題を修正します #6807 @xzhangxian1008
  • 単一のTiFlashノード上で 1,200 万行を超える結果セットを集計するときにTiFlash がエラーを報告する問題を修正 #6993 @windtalker

• ツール

  • バックアップと復元 (BR)

    • PITRリカバリプロセス中のリージョン分割再試行の待機時間が不十分な問題を修正 #42001 @joccau
    • PITRリカバリプロセス中に発生したmemory is limitedエラーによるリカバリ失敗の問題を修正 #41983 @joccau
    • PD ノードがダウンしているときに PITR ログのバックアップの進行状況が進まない問題を修正 #14184 @YuJuncen
    • リージョンリーダーシップの移行時にPITRログバックアップのレイテンシーが増加する問題を軽減する #13638 @YuJuncen

  • TiCDC

    • チェンジフィードを再開するとデータが失われる可能性がある、またはチェックポイントが先に進めないという問題を修正 #8242 @overvenus
    • DDL シンクのデータ競合問題を修正 #8238 @3AceShowHand
    • stoppedステータスの変更フィードが自動的に再起動する可能性がある問題を修正 #8330 @sdojjy
    • すべてのダウンストリーム Kafka サーバーが利用できないときに TiCDCサーバーがパニックになる問題を修正 #8523 @3AceShowHand
    • ダウンストリームがMySQLで、実行されたステートメントがTiDBと互換性がない場合にデータが失われる可能性がある問題を修正します #8453 @asddongmen
    • ローリング アップグレードが TiCDC OOM を引き起こす可能性がある問題、またはチェックポイントがスタックする問題を修正 #8329 @overvenus
    • Kubernetes で TiCDC クラスターの正常なアップグレードが失敗する問題を修正 #8484 @overvenus

  • TiDBデータ移行（DM）

    • DMワーカーノードがGoogle Cloud Storageを使用する際に、ブレークポイントが多すぎるためにGoogle Cloud Storageのリクエスト頻度制限に達し、DMワーカーがGoogle Cloud Storageにデータを書き込めなくなり、結果としてデータ全体の読み込みに失敗する問題を修正しました。 #8482 @maxshuang
    • 複数のDMタスクが同時に同じダウンストリームデータを複製し、すべてがダウンストリームメタデータテーブルを使用してブレークポイント情報を記録する場合、すべてのタスクのブレークポイント情報が同じメタデータテーブルに書き込まれ、同じタスクIDが使用される問題を修正しました。 #8500 @maxshuang

  • TiDB Lightning

    • 物理インポートモードを使用してデータをインポートする場合、対象テーブルの複合主キーにauto_random列が存在するが、ソースデータでその列の値が指定されていない場合、 TiDB Lightning がauto_random列のデータを自動的に生成しない問題を修正しました。 #41454 @D3Hunter
    • 論理インポートモードを使用してデータをインポートする際に、ターゲットクラスターに対するCONFIG権限がないためにインポートが失敗する問題を修正しました #41915 @lichunzhu

寄稿者

TiDBコミュニティの以下の貢献者の皆様に感謝申し上げます。

• アンチトップクォーク
• ブラックティア23
• ボーンチェンジャー
• Dousir9
• エルワドバ
• ハッピーv587
• ジフハスト
• L-メープル
• liumengya94
• ウーフィーザオ
• 夏関