TiDB 7.0.0 リリースノート
発売日：2023年3月30日
TiDB バージョン: DMR
クイックアクセス: クイックスタート | インストールパッケージ
v7.0.0-DMR の主な新機能と改善点は次のとおりです。
| カテゴリー | 特徴 | 説明 |
|---|---|---|
| スケーラビリティとパフォーマンス | セッションレベルの未準備SQLプランキャッシュ(実験的) | 事前に準備ステートメントを手動で設定しなくても、セッション レベルでプラン キャッシュの自動的な再利用をサポートし、コンパイルを削減し、同じ SQL パターンのクエリ時間を短縮します。 |
| TiFlash は、分散storageとコンピューティングアーキテクチャ、および S3 共有storage(実験的) をサポートしています。 | TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入しています。
| |
| 信頼性と可用性 | リソース制御の強化(実験的) | リソース グループを使用して、1 つのクラスター内のさまざまなアプリケーションまたはワークロードにリソースを割り当て、分離することをサポートします。このリリースでは、TiDB にさまざまなリソース バインディング モード (ユーザー、セッション、ステートメント レベル) とユーザー定義の優先順位のサポートが追加されています。また、コマンドを使用してリソースキャリブレーション（リソース全体量の見積り）を行うこともできます。 |
| TiFlash はディスクへのスピルをサポートします | TiFlash は、集計、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、中間結果のディスクへのスピルをサポートしています。 | |
| SQL | 行レベル TTL (GA) | データベース サイズの管理をサポートし、一定の期間を経過したデータを自動的に期限切れにすることでパフォーマンスを向上させます。 |
LIST / RANGEパーティションを再編成する | REORGANIZE PARTITIONステートメントを使用すると、隣接するパーティションを結合したり、1 つのパーティションを複数のパーティションに分割したりすることができ、これによりパーティション テーブルの使いやすさが向上します。 | |
| DB の操作と可観測性 | TiDB はLOAD DATAステートメントの機能を強化します (実験的) | TiDB は、S3/GCS からのデータ インポートのサポートなど、 LOAD DATA SQL ステートメントの機能を強化します。 |
| TiCDC はオブジェクトstorageシンク(GA) をサポートします | TiCDC は、Amazon S3、GCS、Azure Blob Storage、NFS などのオブジェクトstorageサービスへの行変更イベントのレプリケートをサポートしています。 |
機能の詳細
スケーラビリティ
TiFlash は、分散storageとコンピューティングアーキテクチャをサポートし、このアーキテクチャでのオブジェクトstorageをサポートします (実験的) #6882 @ フロービハッピー
v7.0.0 より前では、 TiFlash は結合されたstorageとコンピューティングアーキテクチャのみをサポートしていました。このアーキテクチャでは、各TiFlashノードはstorageとコンピューティング ノードの両方として機能し、そのコンピューティング機能とstorage機能を個別に拡張することはできません。さらに、 TiFlashノードはローカルstorageのみを使用できます。
v7.0.0 以降、 TiFlash は、分散storageとコンピューティングアーキテクチャもサポートします。このアーキテクチャでは、 TiFlashノードは 2 つのタイプ (コンピューティング ノードと書き込みノード) に分けられ、S3 API と互換性のあるオブジェクトstorageをサポートします。どちらのタイプのノードも、コンピューティング容量またはstorage容量に合わせて個別にスケーリングできます。分離されたstorageとコンピューティングアーキテクチャと、結合されたstorageとコンピューティングアーキテクチャを同じクラスター内で使用したり、相互に変換したりすることはできません。 TiFlash を展開するときに使用するアーキテクチャを構成できます。
詳細については、 ドキュメンテーションを参照してください。
パフォーマンス
Fast Online DDL と PITR #38045 @ レヴルスの間の互換性を実現
TiDB v6.5.0 では、 高速オンライン DDL PITRと完全な互換性がありません。完全なデータ バックアップを確実に行うには、まず PITR バックグラウンド バックアップ タスクを停止し、Fast Online DDL を使用してインデックスを迅速に追加してから、PITR バックアップ タスクを再開することをお勧めします。
TiDB v7.0.0 以降、Fast Online DDL と PITR は完全に互換性があります。 PITR を介してクラスター データを復元する場合、互換性を確保するために、ログ バックアップ中に Fast Online DDL を介して追加されたインデックス操作が自動的に再生されます。
詳細については、 ドキュメンテーションを参照してください。
TiFlash は、ヌル対応セミ結合演算子およびヌル対応アンチセミ結合演算子#6674 @ ゲンリキをサポートします。
相関サブクエリで
IN、NOT IN、= ANY、または!= ALL演算子を使用する場合、TiDB はそれらをセミ結合またはアンチセミ結合に変換することでコンピューティング パフォーマンスを最適化します。結合キー列がNULLである可能性がある場合は、 Null 認識セミ結合やNull を認識するアンチセミ結合などの null 対応結合アルゴリズムが必要です。v7.0.0 より前のTiFlash は、null 対応セミ結合演算子および null 対応アンチセミ結合演算子をサポートしていないため、これらのサブクエリがTiFlashに直接プッシュダウンされません。 v7.0.0 以降、 TiFlash はnull 対応セミ結合演算子と null 対応アンチセミ結合演算子をサポートします。 SQL ステートメントにこれらの相関サブクエリが含まれており、クエリ内のテーブルにTiFlashレプリカがあり、 MPPモード有効になっている場合、オプティマイザは、全体のパフォーマンスを向上させるために null 対応セミ結合演算子と null 対応アンチ セミ結合演算子をTiFlashにプッシュダウンするかどうかを自動的に決定します。 。
詳細については、 ドキュメンテーションを参照してください。
TiFlash はFastScan (GA) #5252 @ ホンユニャンの使用をサポートします
v6.3.0 以降、 TiFlash は実験的機能として FastScan を導入します。 v7.0.0 では、この機能が一般利用可能になります。システム変数
tiflash_fastscanを使用して FastScan を有効にできます。この機能は、強力な一貫性を犠牲にすることで、テーブル スキャンのパフォーマンスを大幅に向上させます。対応するテーブルにUPDATEDELETEが含まれず、INSERT操作のみが含まれる場合、FastScan は強い一貫性を維持し、スキャン パフォーマンスを向上させることができます。詳細については、 ドキュメンテーションを参照してください。
TiFlash は後期実体化 (実験的) #5829 @ ロイド・ポティガーをサポートします
フィルタ条件 (
WHERE句) を使用してSELECTステートメントを処理する場合、 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 では、サブクエリの実行プラン キャッシュ制約が削除されます。これは、サブクエリを含む SQL ステートメントの実行プラン
SELECT * FROM t WHERE a > (SELECT ...)など) をキャッシュできるようになったということです。この機能により、実行プラン キャッシュの適用範囲がさらに拡張され、SQL クエリの実行効率が向上します。詳細については、 ドキュメンテーションを参照してください。
TiKV は、ログのリサイクルのための空のログ ファイルの自動生成をサポートしています#14371 @ リククスサシネーター
v6.3.0 では、TiKV は書き込み負荷によって引き起こされるロングテールレイテンシーを削減する機能Raftのリサイクルを導入しました。ただし、ログのリサイクルはRaftログ ファイルの数が特定のしきい値に達した場合にのみ有効になるため、ユーザーがこの機能によってもたらされるスループットの向上を直接体験するのは困難です。
v7.0.0 では、ユーザー エクスペリエンスを向上させるために、
raft-engine.prefill-for-recycleと呼ばれる新しい構成項目が導入されました。この項目は、プロセスの開始時にリサイクルのために空のログ ファイルを生成するかどうかを制御します。この構成を有効にすると、TiKV は初期化中に空のログ ファイルのバッチを自動的に埋め、初期化直後にログのリサイクルが確実に有効になります。詳細については、 ドキュメンテーションを参照してください。
ウィンドウ関数のパフォーマンスを向上させるために、TopN または Limit 演算子をウィンドウ関数から導出するサポート#13936 @ ウィンドトーカー
この機能はデフォルトでは無効になっています。これを有効にするには、セッション変数tidb_opt_derive_topn ～
ONを設定します。詳細については、 ドキュメンテーションを参照してください。
Fast Online DDL #40730 @ タンジェンタによる一意のインデックスの作成をサポート
TiDB v6.5.0 は、Fast Online DDL を介した通常のセカンダリ インデックスの作成をサポートしています。 TiDB v7.0.0 は、Fast Online DDL を介した一意のインデックスの作成をサポートしています。 v6.1.0 と比較して、大きなテーブルへの一意のインデックスの追加は数倍高速になり、パフォーマンスが向上すると予想されます。
詳細については、 ドキュメンテーションを参照してください。
信頼性
リソース制御機能の強化 (実験的) #38825 @ ノールーシュ @ ボーンチェンジャー @ グロルフ @ ティエンチャイアマオ @ コナー1996 @ Jmポテト @ フネス @ キャビンフィーバーB @ ヒューシャープ
TiDB は、リソース グループに基づいたリソース制御機能を強化します。この機能により、TiDB クラスターのリソース利用効率とパフォーマンスが大幅に向上します。リソース制御機能の導入は、TiDB にとってマイルストーンです。分散データベース クラスターを複数の論理ユニットに分割し、さまざまなデータベース ユーザーを対応するリソース グループにマップし、必要に応じて各リソース グループのクォータを設定できます。クラスターのリソースが制限されている場合、同じリソース グループ内のセッションで使用されるすべてのリソースはクォータ内に制限されます。これにより、リソース グループが過剰に消費されても、他のリソース グループのセッションは影響を受けません。
この機能を使用すると、異なるシステムからの複数の中小規模のアプリケーションを単一の TiDB クラスターに結合できます。アプリケーションのワークロードが大きくなっても、他のアプリケーションの通常の動作には影響しません。システムのワークロードが低い場合は、設定されたクォータを超えている場合でも、ビジー状態のアプリケーションに必要なシステム リソースを割り当てることができ、リソースを最大限に活用することができます。さらに、リソース制御機能を合理的に使用することで、クラスタ数を削減し、運用保守の困難を軽減し、管理コストを節約できます。
この機能は、Grafana でのリソースの実際の使用状況を示す組み込みのリソース制御ダッシュボードを提供し、リソースをより合理的に割り当てるのに役立ちます。また、セッション レベルとステートメント レベル (ヒント) の両方に基づいた動的なリソース管理機能もサポートします。この機能の導入により、TiDB クラスターのリソース使用量をより正確に制御し、実際のニーズに基づいてクォータを動的に調整できるようになります。
TiDB v7.0.0 では、リソース グループに絶対スケジュール優先度 (
PRIORITY) を設定して、重要なサービスがリソースを確実に取得できるようにすることができます。また、リソース グループの設定方法も拡張されます。リソース グループは次の方法で使用できます。
- ユーザーレベル。
CREATE USERまたはALTER USERステートメントを使用してユーザーを特定のリソース グループにバインドします。リソース グループをユーザーにバインドすると、ユーザーが新しく作成したセッションは、対応するリソース グループに自動的にバインドされます。 - セッションレベル。現在のセッションで使用されるリソース グループを
SET RESOURCE GROUPで設定します。 - 発言レベル。現在のステートメントで使用されるリソース グループを
RESOURCE_GROUP()で設定します。
詳細については、 ドキュメンテーションを参照してください。
- ユーザーレベル。
Fast Online DDL のチェックポイント メカニズムをサポートし、フォールト トレランスと自動回復機能を向上させます#42164 @ タンジェンタ
TiDB v7.0.0 では、 高速オンライン DDLのチェックポイント メカニズムが導入されており、フォールト トレランスと自動回復機能が大幅に向上しています。 DDL の進行状況を定期的に記録して同期することにより、TiDB DDL 所有者の障害や切り替えが発生した場合でも、進行中の DDL 操作を高速オンライン DDL モードで実行し続けることができます。これにより、DDL の実行がより安定して効率的になります。
詳細については、 ドキュメンテーションを参照してください。
TiFlash はディスク#6528 @ ウィンドトーカーへのスピルをサポートします
実行パフォーマンスを向上させるために、 TiFlash は可能な限りデータ全体をメモリ内で実行します。データ量がメモリの合計サイズを超えると、 TiFlash はメモリ不足によるシステム クラッシュを避けるためにクエリを終了します。したがって、 TiFlashが処理できるデータ量は、利用可能なメモリによって制限されます。
v7.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 @ シュイファングリーンアイズ
v7.0.0 では、TiDB は統計収集ロジックをさらに最適化し、収集時間を約 25% 短縮します。この最適化により、大規模データベース クラスターの運用効率と安定性が向上し、クラスターのパフォーマンスに対する統計収集の影響が軽減されます。
MPP 最適化#39710 @ 懐かしい用の新しいオプティマイザー ヒントを追加
v7.0.0 では、TiDB に、MPP 実行プランの生成に影響を与える一連のオプティマイザー ヒントが追加されています。
SHUFFLE_JOIN(): MPP に有効になります。これは、指定されたテーブルに対してシャッフル結合アルゴリズムを使用するようにオプティマイザーに示唆します。BROADCAST_JOIN(): MPP に有効になります。これは、指定されたテーブルに対してブロードキャスト結合アルゴリズムを使用するようにオプティマイザーに示唆します。MPP_1PHASE_AGG(): MPP に有効になります。これは、指定されたクエリ ブロック内のすべての集計関数に対して 1 フェーズ集計アルゴリズムを使用するようにオプティマイザーに示唆します。MPP_2PHASE_AGG(): MPP に有効になります。これは、指定されたクエリ ブロック内のすべての集計関数に対して 2 フェーズ集計アルゴリズムを使用するようにオプティマイザに示唆します。
MPP オプティマイザーのヒントは、HTAP クエリへの介入に役立ち、HTAP ワークロードのパフォーマンスと安定性を向上させることができます。
詳細については、 ドキュメンテーションを参照してください。
オプティマイザー ヒントは、結合方法と結合順序#36600 @ 懐かしいの指定をサポートします。
v7.0.0 では、オプティマイザ ヒント
LEADING()は結合方法に影響を与えるヒントと組み合わせて使用でき、それらの動作には互換性があります。複数テーブル結合の場合、最適な結合方法と結合順序を効果的に指定できるため、実行計画に対するオプティマイザー ヒントの制御が強化されます。新しいヒントの動作には小さな変更が加えられています。上位互換性を確保するために、TiDB ではシステム変数
tidb_opt_advanced_join_hintが導入されています。この変数がOFFに設定されている場合、オプティマイザー ヒントの動作は以前のバージョンと互換性があります。クラスターを以前のバージョンから v7.0.0 以降のバージョンにアップグレードすると、この変数はOFFに設定されます。より柔軟なヒント動作を取得するには、その動作がパフォーマンスの低下を引き起こさないことを確認した後、この変数をONに設定することを強くお勧めします。詳細については、 ドキュメンテーションを参照してください。
可用性
prefer-leaderオプションをサポートします。これにより、読み取り操作の可用性が向上し、不安定なネットワーク状態での応答レイテンシーが短縮されます#40905 @ リククスサシネーターTiDB のデータ読み取り動作は、システム変数
tidb_replica_readを通じて制御できます。 v7.0.0 では、この変数にprefer-leaderオプションが追加されます。変数がprefer-leaderに設定されている場合、TiDB は読み取り操作を実行するリーダー レプリカの選択を優先します。ディスクやネットワークのパフォーマンスの変動などにより、リーダー レプリカの処理速度が大幅に低下すると、TiDB は他の利用可能なフォロワー レプリカを選択して読み取り操作を実行し、可用性を高め、応答レイテンシーを短縮します。詳細については、 ドキュメンテーションを参照してください。
SQL
生存時間 (TTL) は一般提供されています#39262 @ ルクワンチャオ @ ヤンケオ
TTL は行レベルのライフサイクル制御ポリシーを提供します。 TiDB では、TTL 属性が設定されたテーブルは、構成に基づいて期限切れの行データを自動的にチェックして削除します。 TTL の目標は、クラスターのワークロードへの影響を最小限に抑えながら、ユーザーが時間内に不要なデータを定期的にクリーンアップできるようにすることです。
詳細については、 ドキュメンテーションを参照してください。
サポート
ALTER TABLE…REORGANIZE PARTITION#15000 @ むじょんTiDB は
ALTER TABLE...REORGANIZE PARTITION構文をサポートします。この構文を使用すると、データを失うことなく、テーブルのパーティションの一部またはすべてを、結合、分割、その他の変更を含めて再編成できます。詳細については、 ドキュメンテーションを参照してください。
TiDB はキー パーティショニングをサポートするようになりました。キー パーティショニングとハッシュ パーティショニングはどちらも、データを一定数のパーティションに均等に分散できます。違いは、ハッシュ パーティショニングでは指定された整数式または整数列に基づくデータの分散のみがサポートされるのに対し、キー パーティショニングでは列リストに基づいたデータの分散がサポートされ、キー パーティショニングのパーティショニング列は整数型に限定されないことです。
詳細については、 ドキュメンテーションを参照してください。
DB操作
TiCDC は、storageサービス (GA) #6797 @ ジャオシンユへの変更データのレプリケートをサポートします
TiCDC は、Amazon S3、GCS、Azure Blob Storage、NFS、およびその他の S3 互換storageサービスへの変更データのレプリケートをサポートしています。ストレージサービスは価格も手頃で使いやすいです。 Kafka を使用していない場合は、storageサービスを使用できます。 TiCDC は、変更されたログをファイルに保存し、代わりにそれをstorageサービスに送信します。独自のコンシューマー プログラムは、storageサービスから、新しく生成された変更されたログ ファイルを定期的に読み取ることができます。現在、TiCDC は、変更されたログを canal-json および CSV 形式でstorageサービスにレプリケートすることをサポートしています。
詳細については、 ドキュメンテーションを参照してください。
TiCDC は OpenAPI v2 を提供します。 OpenAPI v1 と比較して、OpenAPI v2 はレプリケーション タスクのより包括的なサポートを提供します。 TiCDC OpenAPI によって提供される機能は、
cdc cliツールのサブセットです。 OpenAPI v2 を介して TiCDC クラスターのクエリと操作を行うことができます。たとえば、TiCDC ノードのステータスの取得、クラスターの健全性ステータスの確認、レプリケーション タスクの管理などが可能です。詳細については、 ドキュメンテーションを参照してください。
Dビーバー v23.0.1 はデフォルトで TiDB をサポートします#17396 @ アイスマップ
- 独立した TiDB モジュール、アイコン、ロゴを提供します。
- デフォルト構成はTiDB サーバーレスをサポートしており、TiDB サーバーレスへの接続が容易になります。
- 外部キー タブを表示または非表示にするための TiDB バージョンの識別をサポートします。
- SQL 実行計画を
EXPLAIN結果で視覚化することをサポートします。 PESSIMISTIC、OPTIMISTIC、AUTO_RANDOM、PLACEMENT、POLICY、REORGANIZE、EXCHANGE、CACHE、NONCLUSTERED、CLUSTEREDなどの TiDB キーワードの強調表示をサポートします。TIDB_BOUNDED_STALENESS、TIDB_DECODE_KEY、TIDB_DECODE_PLAN、TIDB_IS_DDL_OWNER、TIDB_PARSE_TSO、TIDB_VERSION、TIDB_DECODE_SQL_DIGESTS、TIDB_SHARDなどの TiDB関数の強調表示をサポートします。
詳細については、 DBeaver のドキュメントを参照してください。
データ移行
LOAD DATAステートメントの機能を強化し、クラウドstorageからのデータのインポートをサポート (実験的) #40499 @ ランス6716TiDB 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 @ ゴズスキーに送信する際の圧縮転送の有効化をサポートします
v6.6.0 以降、 TiDB Lightning は、TiKV に送信する際のネットワーク転送用にローカルでエンコードおよびソートされたキーと値のペアの圧縮をサポートするため、ネットワーク上で転送されるデータ量が削減され、ネットワーク帯域幅のオーバーヘッドが削減されます。この機能がサポートされる前の以前の TiDB バージョンでは、 TiDB Lightning は比較的広いネットワーク帯域幅を必要とし、データ量が多い場合には高額なトラフィック料金が発生します。
v7.0.0 では、この機能は GA となり、デフォルトで無効になっています。有効にするには、 TiDB Lightningの
compress-kv-pairs設定項目を"gzip"または"gz"に設定します。詳細については、 ドキュメンテーションを参照してください。
互換性の変更
注記：
このセクションでは、v6.6.0 から現在のバージョン (v7.0.0) にアップグレードするときに知っておく必要がある互換性の変更について説明します。 v6.5.0 以前のバージョンから現在のバージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更も確認する必要がある場合があります。
MySQLの互換性
TiDB は、自動インクリメント列がインデックス#40580 @ ティエンチャイアマオでなければならないという制約を削除します。
v7.0.0 より前では、TiDB の動作は MySQL と一致しており、自動インクリメント列がインデックスまたはインデックス プレフィックスである必要があります。 v7.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;v7.0.0 以降、TiDB はキー パーティションをサポートし、MySQL
PARTITION BY LINEAR KEY構文を解析できるようになりました。ただし、TiDB はLINEARキーワードを無視し、代わりに非線形ハッシュ アルゴリズムを使用します。現在、KEYパーティション タイプは、空のパーティション列リストを含むパーティション ステートメントをサポートしていません。詳細については、 ドキュメンテーションを参照してください。
行動の変化
TiCDC は、Avro #8490 @ 3エースショーハンドの
FLOATデータの誤ったエンコードの問題を修正しましたTiCDC クラスターを v7.0.0 にアップグレードするときに、Avro を使用してレプリケートされたテーブルに
FLOATデータ型が含まれている場合、変更フィードがスキーマを正常に更新できるように、アップグレードする前に Confluent Schema Registry の互換性ポリシーを手動でNoneに調整する必要があります。そうしないと、アップグレード後に変更フィードがスキーマを更新できなくなり、エラー状態になります。v7.0.0 以降、
tidb_dml_batch_sizeシステム変数はLOAD DATAステートメントに影響しなくなりました。
システム変数
| 変数名 | 種類の変更 | 説明 |
|---|---|---|
tidb_pessimistic_txn_aggressive_locking | 削除されました | この変数の名前はtidb_pessimistic_txn_fair_lockingに変更されます。 |
tidb_enable_non_prepared_plan_cache | 修正済み | v7.0.0 から有効になり、 準備されていないプラン キャッシュ機能を有効にするかどうかを制御します。 |
tidb_enable_null_aware_anti_join | 修正済み | さらなるテストの後、デフォルト値をOFFからONに変更します。これは、デフォルトで特別な集合演算子NOT INおよび!= ALLによって導かれるサブクエリによってアンチ結合が生成される場合に、TiDB が Null-Aware Hash Join を適用することを意味します。 |
tidb_enable_resource_control | 修正済み | デフォルト値をOFFからONに変更します。これは、クラスターがデフォルトでリソースをリソース グループごとに分離することを意味します。 v7.0.0 ではリソース制御がデフォルトで有効になっているため、いつでもこの機能を使用できます。 |
tidb_non_prepared_plan_cache_size | 修正済み | v7.0.0 から有効になり、キャッシュできる実行プランの最大数を準備されていないプラン キャッシュで制御します。 |
tidb_rc_read_check_ts | 修正済み | v7.0.0 以降、この変数はプリペアドステートメントプロトコルでのカーソル フェッチ読み取りには無効になりました。 |
tidb_enable_inl_join_inner_multi_pattern | 新しく追加された | この変数は、内部テーブルにSelectionまたはProjectionの演算子がある場合にインデックス結合をサポートするかどうかを制御します。 |
tidb_enable_plan_cache_for_subquery | 新しく追加された | この変数は、 プリペアドプランキャッシュ がサブクエリを含むクエリをキャッシュするかどうかを制御します。 |
tidb_enable_plan_replayer_continuous_capture | 新しく追加された | この変数は、 PLAN REPLAYER CONTINUOUS CAPTURE機能を有効にするかどうかを制御します。デフォルト値OFF 、この機能を無効にすることを意味します。 |
tidb_load_based_replica_read_threshold | 新しく追加された | この変数は、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を設定します。この変数によって制御される機能は、TiDB v7.0.0 では完全には機能しません。デフォルト値を変更しないでください。 |
tidb_opt_advanced_join_hint | 新しく追加された | この変数は、結合方法のヒントが結合再順序の最適化に影響を与えるかどうかを制御します。デフォルト値はONで、新しい互換性のある制御モードが使用されることを意味します。値OFF 、v7.0.0 が使用される前の動作を意味します。上位互換性を確保するため、クラスターが以前のバージョンから v7.0.0 以降にアップグレードされると、この変数の値はOFFに設定されます。 |
tidb_opt_derive_topn | 新しく追加された | この変数は、 ウィンドウ関数から TopN または Limit を導出する最適化ルールを有効にするかどうかを制御します。デフォルト値はOFFで、最適化ルールが有効になっていないことを意味します。 |
tidb_opt_enable_late_materialization | 新しく追加された | この変数は、 TiFlash後期マテリアライゼーション機能を有効にするかどうかを制御します。デフォルト値はOFFで、この機能が有効になっていないことを意味します。 |
tidb_opt_ordering_index_selectivity_threshold | 新しく追加された | この変数は、SQL ステートメントにORDER BYとLIMIT節が含まれ、フィルター条件がある場合に、オプティマイザーがインデックスを選択する方法を制御します。 |
tidb_pessimistic_txn_fair_locking | 新しく追加された | 拡張された悲観的ロック解除モデルを有効にして、単一行の競合シナリオでトランザクションの末尾レイテンシーを短縮するかどうかを制御します。デフォルト値はONです。クラスターが以前のバージョンから v7.0.0 以降にアップグレードされると、この変数の値はOFFに設定されます。 |
tidb_ttl_running_tasks | 新しく追加された | この変数は、クラスター全体にわたる TTL タスクの同時実行性を制限するために使用されます。デフォルト値-1 、TTL タスクが TiKV ノードの数と同じであることを意味します。 |
コンフィグレーションファイルのパラメータ
| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類の変更 | 説明 |
|---|---|---|---|
| TiKV | server.snap-max-write-bytes-per-sec | 削除されました | このパラメータの名前はserver.snap-io-max-bytes-per-secに変更されます。 |
| TiKV | raft-engine.enable-log-recycle | 修正済み | デフォルト値はfalseからtrueに変更されます。 |
| TiKV | resolved-ts.advance-ts-interval | 修正済み | デフォルト値は"1s"から"20s"に変更されます。この変更により、Resolved TS の定期的な進行の間隔が長くなり、TiKV ノード間のトラフィック消費が削減されます。 |
| TiKV | resource-control.enabled | 修正済み | デフォルト値はfalseからtrueに変更されます。 |
| TiKV | raft-engine.prefill-for-recycle | 新しく追加された | Raft Engineでログをリサイクルするために空のログ ファイルを生成するかどうかを制御します。デフォルト値はfalseです。 |
| PD | degraded-mode-wait-duration | 新しく追加された | リソース制御に関連する設定項目。縮退モードをトリガーするまでの待ち時間を制御します。デフォルト値は0sです。 |
| PD | read-base-cost | 新しく追加された | リソース制御に関連する設定項目。読み取りリクエストから RU への変換の基本係数を制御します。デフォルト値は0.25です。 |
| PD | read-cost-per-byte | 新しく追加された | リソース制御に関連する設定項目。読み取りフローから RU への変換の基本係数を制御します。デフォルト値は1/ (64 * 1024)です。 |
| PD | read-cpu-ms-cost | 新しく追加された | リソース制御に関連する設定項目。 CPU から RU への変換の基本係数を制御します。デフォルト値は1/3です。 |
| PD | write-base-cost | 新しく追加された | リソース制御に関連する設定項目。書き込みリクエストから RU への変換の基本係数を制御します。デフォルト値は1です。 |
| PD | write-cost-per-byte | 新しく追加された | リソース制御に関連する設定項目。書き込みフローから RU への変換の基本係数を制御します。デフォルト値は1/1024です。 |
| TiFlash | mark_cache_size | 修正済み | 不必要なメモリ使用量を削減するために、 TiFlashのデータ ブロックのメタデータのデフォルトのキャッシュ制限を5368709120から1073741824に変更します。 |
| TiFlash | minmax_index_cache_size | 修正済み | 不必要なメモリ使用量を削減するために、 TiFlashのデータ ブロックの min-max インデックスのデフォルトのキャッシュ制限を5368709120から1073741824に変更します。 |
| TiFlash | flash.disaggregated_mode | 新しく追加された | TiFlashの分散アーキテクチャでは、このTiFlashノードが書き込みノードであるか計算ノードであるかを示します。値はtiflash_writeまたはtiflash_computeです。 |
| TiFlash | storage.s3.endpoint | 新しく追加された | S3 に接続するエンドポイント。 |
| TiFlash | storage.s3.bucket | 新しく追加された | TiFlashがすべてのデータを保存するバケット。 |
| TiFlash | storage.s3.root | 新しく追加された | S3 バケット内のデータstorageのルート ディレクトリ。 |
| TiFlash | storage.s3.access_key_id | 新しく追加された | S3 にアクセスする場合はACCESS_KEY_ID 。 |
| TiFlash | storage.s3.secret_access_key | 新しく追加された | S3 にアクセスする場合はSECRET_ACCESS_KEY 。 |
| TiFlash | storage.remote.cache.dir | 新しく追加された | TiFlash計算ノードのローカル データ キャッシュ ディレクトリ。 |
| TiFlash | storage.remote.cache.capacity | 新しく追加された | TiFlashコンピューティング ノードのローカル データ キャッシュ ディレクトリのサイズ。 |
| TiDB Lightning | add-index-by-sql | 新しく追加された | SQL を使用して物理インポート モードでインデックスを追加するかどうかを制御します。デフォルト値はfalseです。これは、 TiDB Lightning が行データとインデックス データの両方を KV ペアにエンコードし、一緒に TiKV にインポートすることを意味します。 SQL を使用してインデックスを追加する利点は、データのインポートとインデックスのインポートを分離し、データを迅速にインポートできることです。データのインポート後にインデックスの作成に失敗した場合でも、データの整合性は影響を受けません。 |
| TiCDC | enable-table-across-nodes | 新しく追加された | リージョンの数に応じてテーブルを複数の同期範囲に分割するかどうかを決定します。これらの範囲は、複数の TiCDC ノードによって複製できます。 |
| TiCDC | region-threshold | 新しく追加された | enable-table-across-nodesが有効な場合、この機能はregion-threshold以上のリージョンを持つテーブルでのみ有効になります。 |
| DM | analyze | 新しく追加された | CHECKSUM の完了後に各テーブルに対してANALYZE TABLE <table>操作を実行するかどうかを制御します。 "required" / "optional" / "off"として設定できます。デフォルト値は"optional"です。 |
| DM | range-concurrency | 新しく追加された | KV データを TiKV に書き込む dm-worker の同時実行性を制御します。 |
| DM | compress-kv-pairs | 新しく追加された | dm-worker が KV データを TiKV に送信するときに圧縮を有効にするかどうかを制御します。現在、gzip のみがサポートされています。デフォルト値は空で、圧縮しないことを意味します。 |
| DM | pd-addr | 新しく追加された | 物理インポート モードでダウンストリーム PDサーバーのアドレスを制御します。 1 つ以上の PD サーバーを入力できます。この構成項目が空の場合、デフォルトで TiDB クエリからの PD アドレス情報が使用されます。 |
改善点
TiDB
EXPAND演算子を導入して、1 つのステートメントに複数のDISTINCT含む SQL クエリのパフォーマンスを最適化します。SELECTステートメント#16581 @ アイリンキッド- インデックス結合#40505 @ イーサールでより多くの SQL 形式をサポート
- 場合によっては、TiDB でパーティションテーブルデータをグローバルにソートしないでください#26166 @ 定義2014
fair lock modeとlock only if existsの同時使用をサポート#42068 @ ミョンケミンタ- トランザクション低速ログとトランザクション内部イベント#41863 @ エキシウムの印刷をサポート
ILIKEオペレーター#40943 @ xzhangxian1008をサポート
PD
TiFlash
ツール
TiCDC
Kafka がダウンストリームであるシナリオで、単一の大きなテーブルのデータ変更を複数の TiCDC ノードに分散することをサポートします。これにより、大規模な TiDB クラスター#8247 @ オーバーヴィーナスのデータ統合シナリオにおける単一テーブルのスケーラビリティの問題が解決されます。
TiCDC 構成項目
enable_table_across_nodes～trueを設定することで、この機能を有効にできます。region_thresholdを使用すると、テーブルのリージョン数がこのしきい値を超えたときに、TiCDC が対応するテーブルのデータ変更を複数の TiCDC ノードに分散し始めるように指定できます。REDO アプライアでのトランザクションの分割をサポートして、スループットを向上させ、災害復旧シナリオでの RTO を削減します#8318 @ CharlesCheung96
テーブルのスケジューリングを改善して、単一のテーブルをさまざまな TiCDC ノード#8247 @ オーバーヴィーナスにさらに均等に分割します。
MQ シンク#8286 @ こんにちはラスティンにラージ行監視メトリクスを追加します。
リージョンに複数のテーブル#6346 @ オーバーヴィーナスのデータが含まれるシナリオで、TiKV ノードと TiCDC ノード間のネットワーク トラフィックを削減します。
チェックポイント TS と解決済み TS の P99 メトリクス パネルをラグ分析パネル#8524 @ こんにちはラスティンに移動します。
REDO ログ#8361 @ CharlesCheung96での DDL イベントの適用のサポート
アップストリーム書き込みスループット#7720 @ オーバーヴィーナスに基づいて、TiCDC ノードへのテーブルの分割とスケジューリングをサポートします。
TiDB Lightning
TiDB Lightning物理インポート モードは、データ インポートとインデックス インポートの分離をサポートし、インポートの速度と安定性を向上させます#42132 @ ゴズスキー
add-index-by-sqlパラメータを追加します。デフォルト値はfalseです。これは、 TiDB Lightning が行データとインデックス データの両方を KV ペアにエンコードし、それらを一緒に TiKV にインポートすることを意味します。これをtrueに設定すると、 TiDB Lightning が行データのインポート後にADD INDEXSQL ステートメントを介してインデックスを追加し、インポートの速度と安定性が向上することを意味します。tikv-importer.keyspace-nameパラメータを追加します。デフォルト値は空の文字列です。これは、 TiDB Lightning が、データをインポートするために対応するテナントのキースペース名を自動的に取得することを意味します。値を指定すると、指定したキースペース名がデータのインポートに使用されます。このパラメータにより、マルチテナント TiDB クラスターにデータをインポートする際のTiDB Lightningの構成に柔軟性が与えられます。 #41915 @ リチュンジュ
バグの修正
TiDB
- TiDB を v6.5.1 から以降のバージョン#41502 @ クリサンにアップグレードするときに更新が欠落する問題を修正
- #41423 @ クレイジークス520のアップグレード後に一部のシステム変数のデフォルト値が変更されない問題を修正
- インデックスの追加に関連するコプロセッサーのリクエスト タイプが不明#41400 @ タンジェンタとして表示される問題を修正
- インデックス#41515 @ タンジェンタを追加するときに「PessimisticLockNotFound」を返す問題を修正
- 一意のインデックス#41630 @ タンジェンタを追加するときに誤って
found duplicate keyを返す問題を修正 - インデックス#41880 @ タンジェンタを追加するときのpanicの問題を修正
- TiFlash が実行中に生成された列のエラーを報告する問題を修正#40663 @ グオシャオゲ
- 時間タイプ#41938 @ シュイファングリーンアイズがある場合、TiDB が統計を正しく取得できない場合がある問題を修正
- 準備されたプラン キャッシュが有効になっている場合にフル インデックス スキャンでエラーが発生する可能性がある問題を修正します#42150 @ fzzf678
IFNULL(NOT NULL COLUMN, ...)が間違った結果#41734 @ リトルフォールを返す可能性がある問題を修正- パーティションテーブル内のすべてのデータが単一のリージョン#41801 @ 定義2014にある場合、TiDB が誤った結果を生成する可能性がある問題を修正します。
- 単一の SQL ステートメント#42135 @ むじょんに異なるパーティション分割テーブルが含まれる場合、TiDB が誤った結果を生成する可能性がある問題を修正します。
- パーティションテーブル#41638 @ シュイファングリーンアイズに新しいインデックスを追加した後、パーティションテーブルテーブルで統計の自動収集が正しくトリガーされないことがある問題を修正します。
- 統計を 2 回続けて収集した後、TiDB が間違った列統計情報を読み取る可能性がある問題を修正します#42073 @ シュイファングリーンアイズ
- プラン キャッシュの準備が有効になっている場合に IndexMerge が誤った結果を生成する可能性がある問題を修正します#41828 @ qw4990
- IndexMerge で goroutine リーク#41605 @ グオシャオゲが発生する可能性がある問題を修正
- 非 BIGINT 符号なし整数が文字列/10 進数#41736 @ リトルフォールと比較されたときに誤った結果を生成する可能性がある問題を修正
- メモリ制限の超過により前の
ANALYZEステートメントを強制終了すると、同じセッション内の現在のANALYZEステートメントが強制終了される可能性がある問題を修正します#41825 @ 徐淮嶼 - バッチコプロセッサ#41412 @ あなた06の情報収集処理中にデータ競合が発生することがある問題を修正
- アサーション エラーにより、パーティション テーブル#40629 @ エキシウムの MVCC 情報が出力されない問題を修正します。
- フェア ロック モードにより、存在しないキー#41527 @ エキシウムにロックが追加される問題を修正
INSERT IGNOREおよびREPLACEステートメントが、値#42121 @ ジグアンを変更しないキーをロックしない問題を修正します。
PD
TiFlash
ツール
バックアップと復元 (BR)
TiCDC
- 変更フィードを再開するとデータが失われる可能性がある、またはチェックポイントが#8242 @ オーバーヴィーナス進むことができないという問題を修正します。
- DDL シンク#8238 @ 3エースショーハンドのデータ競合の問題を修正
stoppedステータスのチェンジフィードが自動的に#8330 @ スドジで再起動する場合がある問題を修正- すべてのダウンストリーム Kafka サーバーが利用できない場合に TiCDCサーバーがパニックになる問題を修正#8523 @ 3エースショーハンド
- ダウンストリームが MySQL で、実行されたステートメントが TiDB #8453 @ 東門と互換性がない場合にデータが失われる可能性がある問題を修正
- ローリング アップグレードによって TiCDC OOM が発生する可能性があるか、チェックポイントが#8329 @ オーバーヴィーナスでスタックする問題を修正します。
- Kubernetes #8484 @ オーバーヴィーナスで TiCDC クラスターの正常なアップグレードが失敗する問題を修正
TiDB データ移行 (DM)
- DM ワーカー ノードが Google Cloud Storage を使用する場合、ブレークポイントが頻繁すぎるため、Google Cloud Storage のリクエスト頻度制限に達し、DM ワーカーが Google Cloud Storage にデータを書き込むことができず、完全なデータの書き込みが失敗する問題を修正します。 #8482 @ マックスシュアンをロードするには
- 複数の DM タスクが同じダウンストリーム データを同時にレプリケートし、すべてがダウンストリーム メタデータ テーブルを使用してブレークポイント情報を記録する場合、すべてのタスクのブレークポイント情報が同じメタデータ テーブルに書き込まれ、同じタスク ID #8500が使用される問題を修正します。 @ マックスシュアン
TiDB Lightning
貢献者
TiDB コミュニティの以下の貢献者に感謝いたします。