TiDB 7.0.0 リリースノート
発売日: 2023年3月30日
TiDB バージョン: 7.0.0- DMMR の
クイックアクセス: クイックスタート
v7.0.0-DMR の主な新機能と改善点は次のとおりです。
| カテゴリ | 特徴 | 説明 |
|---|---|---|
| スケーラビリティとパフォーマンス | セッション レベルの非準備 SQL プラン キャッシュ(実験的) | セッション レベルでプラン キャッシュを自動的に再利用することをサポートします。これにより、事前に準備ステートメントを手動で設定しなくても、コンパイルが削減され、同じ SQL パターンのクエリ時間が短縮されます。 |
| TiFlash は、分散storageとコンピューティングアーキテクチャ、および S3 共有storage(実験的) をサポートします。 | TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入します。
| |
| 信頼性と可用性 | リソース制御の強化（実験的） | リソース グループを使用して、1 つのクラスター内のさまざまなアプリケーションまたはワークロードのリソースを割り当て、分離することをサポートします。このリリースでは、TiDB はさまざまなリソース バインディング モード (ユーザー、セッション、ステートメント レベル) とユーザー定義の優先順位のサポートを追加します。さらに、コマンドを使用してリソース調整 (全体のリソース量の推定) を実行することもできます。 |
| TiFlashはディスクへの書き込みをサポート | TiFlash は、集約、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、ディスクへの中間結果のスピルをサポートします。 | |
| 構文 | 行レベルの 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をデプロイするときに、使用するアーキテクチャを構成できます。
詳細についてはドキュメント参照してください。
パフォーマンス
高速オンラインDDLとPITR ＃38045 @ リーヴルス間の互換性を実現
TiDB v6.5.0 では、 高速オンラインDDL ピトルと完全に互換性がありません。完全なデータ バックアップを確実に行うには、まず PITR バックグラウンド バックアップ タスクを停止し、Fast Online DDL を使用してインデックスをすばやく追加してから、PITR バックアップ タスクを再開することをお勧めします。
TiDB v7.0.0 以降、Fast Online DDL と PITR は完全に互換性があります。PITR を介してクラスター データを復元する場合、ログ バックアップ中に Fast Online DDL によって追加されたインデックス操作は、互換性を実現するために自動的に再生されます。
詳細についてはドキュメント参照してください。
TiFlash は、 null 認識のセミ結合演算子と null 認識のアンチセミ結合演算子＃6674 @ ゲンリキをサポートしています。
相関サブクエリで
IN、NOT IN、= ANY、または!= ALL演算子を使用する場合、TiDB はそれらをセミ結合またはアンチセミ結合に変換して計算パフォーマンスを最適化します。結合キー列がNULLなる可能性がある場合は、 Null 認識セミ結合やNull 認識アンチセミ結合などの null 認識結合アルゴリズムが必要です。v7.0.0 より前のTiFlashでは、null 対応のセミ結合演算子と null 対応のアンチ セミ結合演算子がサポートされていないため、これらのサブクエリがTiFlashに直接プッシュダウンされませんでした。v7.0.0 以降、 TiFlashnull 対応のセミ結合演算子と null 対応のアンチ セミ結合演算子がサポートされます。SQL ステートメントにこれらの相関サブクエリが含まれ、クエリ内のテーブルにTiFlashレプリカがあり、 MPPモード有効になっている場合、オプティマイザーは、全体的なパフォーマンスを向上させるために、null 対応のセミ結合演算子と null 対応のアンチ セミ結合演算子をTiFlashにプッシュダウンするかどうかを自動的に決定します。
詳細についてはドキュメント参照してください。
TiFlashはFastScan (GA) ＃5252 @ ホンユンヤンの使用をサポートします
v6.3.0 以降、 TiFlash はFastScan を実験的機能として導入しました。v7.0.0 では、この機能が一般公開されます。システム変数
tiflash_fastscanを使用して FastScan を有効にすることができます。この機能は、強力な一貫性を犠牲にすることで、テーブル スキャンのパフォーマンスを大幅に向上させます。対応するテーブルにUPDATE操作がなくINSERT操作のみが含まれる場合、FastScan は強力な一貫性を維持し、スキャン パフォーマンスDELETE向上させることができます。詳細についてはドキュメント参照してください。
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 @ ふーふーの実行プランキャッシュ制約を削除します。
TiDB v7.0.0 では、サブクエリの実行プラン キャッシュ制約が削除されました。つまり、
SELECT * FROM t WHERE a > (SELECT ...)のように、サブクエリを含む SQL ステートメントの実行プランをキャッシュできるようになりました。この機能により、実行プラン キャッシュの適用範囲がさらに広がり、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に設定します。詳細についてはドキュメント参照してください。
高速オンライン DDL ＃40730 @ タンジェンタによる一意のインデックスの作成をサポート
TiDB v6.5.0 は、Fast Online DDL による通常のセカンダリ インデックスの作成をサポートしています。TiDB v7.0.0 は、Fast Online DDL による一意のインデックスの作成をサポートしています。v6.1.0 と比較すると、大規模なテーブルに一意のインデックスを追加すると、パフォーマンスが向上し、数倍高速化されることが期待されます。
詳細についてはドキュメント参照してください。
信頼性
リソース制御機能の強化 (実験的) ＃38825 @ ノルーシュ @ ボーンチェンジャー @ 栄光 @ 天菜まお @ コナー1996 @ じゃがいも @ ネス @ キャビンフィーバーB @ ヒューシャープ
TiDB は、リソース グループに基づくリソース制御機能を強化しました。この機能により、TiDB クラスターのリソース利用効率とパフォーマンスが大幅に向上します。リソース制御機能の導入は、TiDB にとって画期的な出来事です。分散データベース クラスターを複数の論理ユニットに分割し、異なるデータベース ユーザーを対応するリソース グループにマップし、必要に応じて各リソース グループのクォータを設定できます。クラスター リソースが制限されている場合、同じリソース グループ内のセッションで使用されるすべてのリソースはクォータに制限されます。このように、リソース グループが過剰に消費されても、他のリソース グループのセッションには影響しません。
この機能により、異なるシステムの複数の中小規模のアプリケーションを 1 つの TiDB クラスターに統合できます。アプリケーションのワークロードが大きくなっても、他のアプリケーションの正常な動作には影響しません。システムのワークロードが低い場合は、設定されたクォータを超えても、ビジー状態のアプリケーションに必要なシステム リソースを割り当てることができるため、リソースを最大限に活用できます。さらに、リソース制御機能を合理的に使用すると、クラスターの数を減らし、運用と保守の難しさを軽減し、管理コストを節約できます。
この機能は、Grafana のリソースの実際の使用状況を表示する組み込みのリソース コントロール ダッシュボードを提供し、リソースをより合理的に割り当てるのに役立ちます。また、セッション レベルとステートメント レベルの両方に基づく動的なリソース管理機能もサポートしています (ヒント)。この機能の導入により、TiDB クラスターのリソース使用状況をより正確に制御し、実際のニーズに基づいてクォータを動的に調整できるようになります。
TiDB v7.0.0 では、重要なサービスがリソースを取得できることを保証するために、リソース グループに絶対的なスケジュール優先度 (
PRIORITY) を設定できます。また、リソース グループの設定方法も拡張されます。リソース グループは次の方法で使用できます。
- ユーザー レベル。1 または
CREATE USERALTER USERステートメントを使用して、ユーザーを特定のリソース グループにバインドします。リソース グループをユーザーにバインドすると、ユーザーによって新しく作成されたセッションは、対応するリソース グループに自動的にバインドされます。 - セッション レベル。
SET RESOURCE GROUPを介して現在のセッションで使用されるリソース グループを設定します。 - ステートメント レベル。
RESOURCE_GROUP()を介して現在のステートメントで使用されるリソース グループを設定します。
詳細についてはドキュメント参照してください。
- ユーザー レベル。1 または
高速オンライン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) を調整することで、演算子が使用できるメモリの最大量を制御できます。演算子によって使用されるメモリがしきい値を超えると、自動的にデータがディスクに書き込まれます。これにより、パフォーマンスが多少犠牲になりますが、より多くのデータを処理できるようになります。詳細についてはドキュメント参照してください。
v7.0.0 では、TiDB は統計収集のロジックをさらに最適化し、収集時間を約 25% 短縮しました。この最適化により、大規模なデータベース クラスターの運用効率と安定性が向上し、統計収集がクラスターのパフォーマンスに与える影響が軽減されます。
MPP 最適化＃39710 @ 思い出させるの新しいオプティマイザーヒントを追加します
v7.0.0 では、TiDB は MPP 実行プランの生成に影響を与える一連のオプティマイザーヒントを追加します。
SHUFFLE_JOIN(): MPP に有効です。指定されたテーブルに対して Shuffle Join アルゴリズムを使用するようにオプティマイザに指示します。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_replica_readを通じて、TiDB のデータ読み取り動作を制御できます。v7.0.0 では、この変数にprefer-leaderオプションが追加されました。変数をprefer-leaderに設定すると、TiDB はリーダー レプリカを選択して読み取り操作を実行することを優先します。ディスクやネットワークのパフォーマンスの変動などにより、リーダー レプリカの処理速度が大幅に低下した場合、TiDB は他の利用可能なフォロワー レプリカを選択して読み取り操作を実行し、可用性を高め、応答のレイテンシーを短縮します。詳細についてはドキュメント参照してください。
構文
有効期間（TTL）は一般に＃39262 @ lcwangchao @ ヤンケオで利用可能
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ツールのサブセットです。TiCDC ノードのステータスの取得、クラスターのヘルス ステータスの確認、レプリケーション タスクの管理など、OpenAPI v2 を介して TiCDC クラスターを照会および操作できます。詳細についてはドキュメント参照してください。
DBeaver v23.0.1 はデフォルトで TiDB をサポートします＃17396 @ アイスマップ
- 独立した TiDB モジュール、アイコン、ロゴを提供します。
- デフォルト構成ではTiDB Cloudサーバーレスサポートされているため、 TiDB Cloud Serverless への接続が容易になります。
- 外部キー タブを表示または非表示にするために TiDB のバージョンを識別することをサポートします。
EXPLAINの結果で SQL 実行プランの視覚化をサポートします。PESSIMISTICPLACEMENTOPTIMISTICAUTO_RANDOMキーワードNONCLUSTERED強調CACHECLUSTEREDサポートREORGANIZEEXCHANGEPOLICYTIDB_BOUNDED_STALENESSTIDB_DECODE_PLANTIDB_IS_DDL_OWNERTiDB関数TIDB_DECODE_KEY強調表示TIDB_SHARDサポートTIDB_PARSE_TSOTIDB_VERSIONTIDB_DECODE_SQL_DIGESTS
詳細については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に調整して、changefeed がスキーマを正常に更新できるようにする必要があります。そうしないと、アップグレード後に changefeed がスキーマを更新できず、エラー状態になります。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によって導かれるサブクエリによって Anti Join が生成される場合、TiDB は Null 対応ハッシュ結合を適用します。 |
tidb_enable_resource_control | 修正済み | デフォルト値をOFFからONに変更します。これは、クラスターがデフォルトでリソース グループごとにリソースを分離することを意味します。リソース制御はバージョン 7.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 ノードの数と同じであることを意味します。 |
コンフィグレーションファイルのパラメータ
| コンフィグレーションファイル | コンフィグレーションパラメータ | タイプを変更 | 説明 |
|---|---|---|---|
| ティクヴ | server.snap-max-write-bytes-per-sec | 削除されました | このパラメータの名前はserver.snap-io-max-bytes-per-secに変更されました。 |
| ティクヴ | raft-engine.enable-log-recycle | 修正済み | デフォルト値はfalseからtrueに変更されます。 |
| ティクヴ | resolved-ts.advance-ts-interval | 修正済み | デフォルト値は"1s"から"20s"に変更されます。この変更により、解決済み TS の定期的な進行間隔が長くなり、TiKV ノード間のトラフィック消費が削減されます。 |
| ティクヴ | resource-control.enabled | 修正済み | デフォルト値はfalseからtrueに変更されます。 |
| ティクヴ | 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のデータ ブロックの最小最大インデックスのデフォルトのキャッシュ制限を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 を使用してインデックスを追加する利点は、データのインポートとインデックスのインポートを分離し、データをすばやくインポートできることです。データのインポート後にインデックスの作成が失敗しても、データの一貫性は影響を受けません。 |
| ティCDC | enable-table-across-nodes | 新しく追加された | リージョンの数に応じて、テーブルを複数の同期範囲に分割するかどうかを決定します。これらの範囲は、複数の TiCDC ノードによって複製できます。 |
| ティCDC | 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 アドレス情報が使用されます。 |
改善点
ティビ
- 1 つの
SELECTに複数のDISTINCT含まれる SQL クエリのパフォーマンスを最適化するためにEXPAND演算子を導入します＃16581 @ アイリンキッド - インデックス結合#40505 @ イサールの SQL 形式をさらにサポート
- 場合によっては TiDB でパーティションテーブルデータをグローバルにソートしないようにする＃26166 @ 定義2014
fair lock modeとlock only if exists同時に使用してサポート＃42068 @ ミョンケミンタ- トランザクションスローログとトランザクション内部イベントの印刷をサポート＃41863 @ エキシウム
ILIKEオペレータ＃40943 @ 翻訳者をサポート
- 1 つの
PD
TiFlash
ツール
ティCDC
Kafka がダウンストリームであるシナリオで、単一の大きなテーブルのデータ変更を複数の TiCDC ノードに分散することをサポートし、大規模な TiDB クラスターのデータ統合シナリオにおける単一テーブルのスケーラビリティの問題を解決します＃8247 @ 金星の上
この機能を有効にするには、TiCDC 構成項目
enable_table_across_nodesをtrueに設定します。5region_threshold使用すると、テーブルのリージョン数がこのしきい値を超えると、TiCDC が対応するテーブルのデータ変更を複数の TiCDC ノードに配布し始めるように指定できます。災害復旧シナリオでのスループットの向上とRTOの短縮のために、REDOアプライヤでのトランザクション分割をサポートする＃8318 @ チャールズ・チュン96
テーブル スケジューリングを改善して、1 つのテーブルをさまざまな TiCDC ノード＃8247 @ 金星の上に均等に分割します。
リージョンに複数のテーブル＃6346 @ 金星の上のデータが含まれているシナリオで、TiKV ノードと TiCDC ノード間のネットワーク トラフィックを削減します。
REDOログ＃8361 @ チャールズ・チュン96への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 を v6.5.1 からそれ以降のバージョン＃41502 @ クリサンにアップグレードするときに更新が失われる問題を修正しました
- ＃41423 @ クレイジーcs520にアップグレードした後、一部のシステム変数のデフォルト値が変更されない問題を修正しました
- インデックスの追加に関連するコプロセッサー要求タイプが不明＃41400 @ タンジェンタとして表示される問題を修正
- インデックス＃41515 @ タンジェンタを追加するときに「PessimisticLockNotFound」が返される問題を修正しました
- 一意のインデックス＃41630 @ タンジェンタを追加するときに誤って
found duplicate keyを返す問題を修正しました - インデックス＃41880 @ タンジェンタを追加するときに発生するpanic問題を修正
- 実行中にTiFlash が生成された列のエラーを報告する問題を修正＃40663 @ グオシャオゲ
- 時間タイプ＃41938 @ 翻訳者がある場合に TiDB が統計を正しく取得できない可能性がある問題を修正しました。
- 準備済みプランキャッシュが有効になっている場合にフルインデックススキャンでエラーが発生する可能性がある問題を修正＃42150 @ ふーふー
IFNULL(NOT NULL COLUMN, ...)誤った結果を返す可能性がある問題を修正＃41734 @ リトルフォール- パーティションテーブル内のすべてのデータが単一のリージョン＃41801 @ 定義2014にある場合に TiDB が誤った結果を生成する可能性がある問題を修正しました。
- 単一の SQL ステートメントに異なるパーティション テーブルが出現すると、TiDB が誤った結果を生成する可能性がある問題を修正しました＃42135 @ ミョンス
- パーティションテーブルに新しいインデックスを追加した後、パーティションテーブルテーブルで統計の自動収集が正しくトリガーされない可能性がある問題を修正しました＃41638 @ 翻訳者
- 統計を2回連続で収集した後にTiDBが誤った列統計情報を読み取る可能性がある問題を修正＃42073 @ 翻訳者
- 準備プランキャッシュが有効になっている場合に IndexMerge が誤った結果を生成する可能性がある問題を修正＃41828 @ qw4990
- IndexMerge で goroutine リークが発生する可能性がある問題を修正＃41605 @ グオシャオゲ
- BIGINT 以外の符号なし整数を文字列/小数と比較すると誤った結果が生成される可能性がある問題を修正＃41736 @ リトルフォール
- メモリ制限超過により前の
ANALYZEステートメントを強制終了すると、同じセッション内の現在のANALYZEステートメントが＃41825 @ 徐懐玉で強制終了される可能性がある問題を修正しました。 - バッチコプロセッサ＃41412 @ あなた06の情報収集処理中にデータ競合が発生する可能性がある問題を修正
- アサーションエラーによりパーティションテーブル＃40629 @ エキシウムの MVCC 情報が印刷されない問題を修正しました。
- フェアロックモードで存在しないキー＃41527 @ エキシウムにロックが追加される問題を修正
INSERT IGNOREとREPLACEステートメントが値＃42121 @ ジグアンを変更しないキーをロックしない問題を修正しました
PD
TiFlash
ツール
バックアップと復元 (BR)
ティCDC
- 変更フィードを再開するとデータが失われる可能性がある、またはチェックポイントが＃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 コミュニティの以下の貢献者に感謝いたします。