TiDB 7.2.0 リリースノート

発売日：2023年6月29日

TiDB バージョン: 7.2.0

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

バージョン7.2.0では、以下の主要な機能と改善点が導入されています。

機能の詳細

パフォーマンス

• TiFlash #7427 @xzhangxian1008への次の 2 つのウィンドウ関数プッシュ ダウンをサポートします。

  • FIRST_VALUE
  • LAST_VALUE

• TiFlashはパイプライン実行モデルをサポートします（実験的） #6518 @SeaRise

  バージョン7.2.0より前は、 TiFlashエンジン内の各タスクは実行時に個別にスレッドリソースを要求する必要がありました。TiFlashはタスク数を制御することでスレッドリソースの使用量を制限し、過剰使用を防いでいましたが、この問題を完全に解消することはできませんでした。この問題に対処するため、バージョン7.2.0以降、 TiFlashはパイプライン実行モデルを導入しました。このモデルでは、すべてのスレッドリソースを一元的に管理し、タスクの実行を均一にスケジュールすることで、リソースの過剰使用を回避しながらスレッドリソースの利用率を最大化します。パイプライン実行モデルを有効または無効にするには、システム変数tidb_enable_tiflash_pipeline_modelを変更してください。

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

• TiFlash はスキーマ複製のレイテンシーを削減します #7630 @hongyunyan

  テーブルのスキーマが変更されると、 TiFlash はTiKV から最新のスキーマをタイムリーにレプリケートする必要があります。v7.2.0 より前のバージョンでは、 TiFlash がテーブルデータにアクセスし、データベース内のテーブルスキーマの変更を検出すると、 TiFlashレプリカを持たないテーブルも含め、このデータベース内のすべてのテーブルのスキーマを再度レプリケートする必要がありました。そのため、テーブル数の多いデータベースでは、 TiFlashを使用して単一のテーブルからデータを読み取る場合でも、 TiFlash がすべてのテーブルのスキーマ複製を完了するまで待機する必要があり、かなりのレイテンシーが発生する可能性があります。

  バージョン7.2.0では、 TiFlashのスキーマレプリケーションメカニズムが最適化され、 TiFlashレプリカを持つテーブルのスキーマのみをレプリケートするようになりました。TiFlashレプリカを持つテーブルでスキーマ変更が検出されると、 TiFlashはそのテーブルのスキーマのみをレプリケートします。これにより、 TiFlashのスキーマレプリケーションのレイテンシーが短縮され、DDL操作がTiFlashデータレプリケーションに与える影響が最小限に抑えられます。この最適化は自動的に適用され、手動での設定は不要です。

• 統計情報の収集パフォーマンスを改善する #44725 @xuyifangreeneyes

  TiDB v7.2.0では、統計情報の収集戦略が最適化され、重複情報やオプティマイザにとって価値の低い情報がスキップされるようになりました。統計情報の収集速度は全体で30%向上しています。この改善により、TiDBはデータベースの統計情報をより迅速に更新できるようになり、生成される実行プランの精度が向上し、結果としてデータベース全体のパフォーマンスが向上します。

  デフォルトでは、統計情報の収集ではJSON 、 BLOB 、 MEDIUMBLOB 、およびLONGBLOB型の列がスキップされます。デフォルトの動作は、 tidb_analyze_skip_column_typesシステム変数を設定することで変更できます。TiDB はJSON 、 BLOB 、およびTEXT型とそのサブタイプのスキップをサポートしています。

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

• データとインデックスの一貫性チェックのパフォーマンスを改善 #43693 @wjhuang2016

  ADMIN CHECK [TABLE|INDEX]ステートメントは、テーブル内のデータとそれに対応するインデックスとの整合性をチェックするために使用されます。v7.2.0 では、TiDB はデータ整合性チェックの方法を最適化し、 ADMIN CHECK [TABLE|INDEX]の実行効率を大幅に向上させました。大量のデータを扱うシナリオでは、この最適化によりパフォーマンスが数百倍向上する可能性があります。

  最適化はデフォルトで有効になっており（ tidb_enable_fast_table_checkはデフォルトでONです）、大規模テーブルにおけるデータ整合性チェックに必要な時間を大幅に短縮し、運用効率を向上させます。

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

信頼性

• 予想よりも多くのリソースを消費するクエリを自動的に管理する (実験的) #43691 @Connor1996 @glorvキャビンフィーバーB @グロルヴ@HuSharp @nolouch

  データベースの安定性に対する最も一般的な課題は、SQLのパフォーマンス問題が突発的に発生することによるデータベース全体のパフォーマンス低下です。SQLのパフォーマンス問題には、十分にテストされていない新しいSQL文、データ量の急激な変化、実行プランの急激な変更など、多くの原因があります。これらの問題を根本から完全に回避することは困難です。TiDB v7.2.0では、想定よりも多くのリソースを消費するクエリを管理する機能を提供しています。この機能により、パフォーマンス問題が発生した場合の影響範囲を迅速に縮小できます。

  これらのクエリを管理するために、リソースグループごとにクエリの最大実行時間を設定できます。クエリの実行時間がこの制限を超えると、クエリの優先度が自動的に下げられるか、キャンセルされます。また、テキストまたは実行プランに基づいて特定されたクエリを即座に照合する期間を設定することもできます。これにより、特定フェーズ中に問題のあるクエリが多数同時実行されることを防ぎ、想定以上のリソース消費を回避できます。

  想定以上のリソースを消費するクエリを自動的に管理することで、予期せぬクエリパフォーマンスの問題に迅速に対応できる効果的な手段が得られます。この機能は、問題がデータベース全体のパフォーマンスに与える影響を軽減し、データベースの安定性を向上させます。

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

• 過去の実行計画に基づいてバインディングを作成する機能を強化する #39199 @qw4990

  TiDB v7.2.0 は過去の実行計画に従ってバインディングを作成する機能を強化します。この機能により、複雑なステートメントの解析とバインドのプロセスが改善され、バインディングがより安定し、次の新しいヒントがサポートされます。

  • AGG_TO_COP()
  • LIMIT_TO_COP()
  • ORDER_INDEX
  • NO_ORDER_INDEX()

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

• オプティマイザー修正制御メカニズムを導入して、オプティマイザーの動作をきめ細かく制御できるようにします #43169 @time-and-fate

  より適切な実行プランを生成するため、TiDB オプティマイザの動作は製品のバージョンアップごとに進化しています。しかし、特定のシナリオでは、変更によってパフォーマンスが低下する場合があります。TiDB v7.2.0 では、オプティマイザの細かい動作を制御できるオプティマイザ修正コントロールが導入されました。これにより、一部の新しい変更をロールバックしたり、制御したりすることが可能になります。

  制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべてオプティマオプティマイザー修正コントロールにリストされています。動作制御を実現するためにtidb_opt_fix_controlシステム変数を設定することにより、1 つ以上の動作の目標値を設定できます。

  オプティマイザ修正制御メカニズムを使用すると、TiDBオプティマイザをきめ細かく制御できます。これにより、アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段が提供され、TiDBの安定性が向上します。

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

• 軽量統計初期化が一般提供開始 (GA) #42160 @xuyifangreeneyes

  バージョン7.2.0以降、軽量統計初期化機能が一般提供（GA）となりました。軽量統計初期化機能により、起動時にロードする必要のある統計情報の数を大幅に削減できるため、統計情報のロード速度が向上します。この機能は、複雑な実行環境におけるTiDBの安定性を高め、TiDBノードの再起動時にサービス全体への影響を軽減します。

  v7.2.0以降のバージョンで新規作成されたクラスタの場合、TiDBはデフォルトでTiDB起動時に軽量統計情報をロードし、ロードが完了するまでサービスの提供を待ちます。以前のバージョンからアップグレードしたクラスタの場合は、TiDB構成項目lite-init-statsとforce-init-statsをtrueに設定することで、この機能を有効にできます。

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

SQL

• CHECK制約のサポート #41711 @fzzf678

  バージョン7.2.0以降では、 CHECK制約を使用して、テーブル内の1つまたは複数の列の値を、指定した条件を満たすように制限できます。 CHECK制約がテーブルに追加されると、TiDBはテーブルにデータを挿入または更新する前に、その制約が満たされているかどうかを確認します。制約を満たすデータのみが書き込まれます。

  この機能はデフォルトでは無効になっています。有効にするには、 tidb_enable_check_constraintシステム変数をONに設定してください。

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

データベース操作

• DDL ジョブは操作の一時停止と再開をサポートします (実験的) #18015 @godouxm

  TiDB v7.2.0より前は、DDLジョブの実行中に業務のピークが発生した場合、業務への影響を軽減するには、DDLジョブを手動でキャンセルするしかありませんでした。v7.2.0では、TiDBはDDLジョブの一時停止と再開操作を導入しました。これらの操作により、ピーク時にDDLジョブを一時停止し、ピーク終了後に再開できるため、アプリケーションのワークロードへの影響を回避できます。

  例えば、 ADMIN PAUSE DDL JOBSまたはADMIN RESUME DDL JOBSを使用して、複数の DDL ジョブを一時停止および再開できます。

  ADMIN PAUSE DDL JOBS 1,2;
  ADMIN RESUME DDL JOBS 1,2;
  

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

データ移行

• データインポート効率を大幅に向上させる新しいSQLステートメントIMPORT INTOを導入（実験的） #42930 @D3Hunter

  IMPORT INTOステートメントは、 TiDB Lightningの物理輸入モード機能を統合します。このステートメントを使用すると、CSV、SQL、PARQUET などの形式のデータを TiDB の空のテーブルにすばやくインポートできます。このインポート方法により、 TiDB Lightningの個別のデプロイと管理が不要になり、データインポートの複雑さが軽減され、インポート効率が大幅に向上します。

  Amazon S3 または GCS に保存されているデータ ファイルの場合、 TiDB分散実行フレームワーク（DXF）が有効になっていると、 IMPORT INTOは、データ インポート ジョブを複数のサブ ジョブに分割し、それらを複数の TiDB ノードにスケジュールして並列インポートを行うこともサポートしており、インポート パフォーマンスをさらに向上させます。

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

• TiDB Lightningは、 Latin-1文字セットのソースファイルをTiDBにインポートすることをサポートします #44434 @lance6716

  この機能を使用すると、 TiDB Lightningを使用して、Latin-1 文字セットのソースファイルを TiDB に直接インポートできます。v7.2.0 より前のバージョンでは、このようなファイルをインポートするには、追加の前処理または変換が必要でした。v7.2.0 以降では、 TiDB Lightningインポートタスクを設定する際にcharacter-set = "latin1"を指定するだけで済みます。その後、 TiDB Lightning はインポート処理中に文字セットの変換を自動的に処理し、データの整合性と正確性を確保します。

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

互換性の変更

注記：

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

行動の変化

• 更新イベントを処理する際、TiCDC は、イベント内で主キーまたは NULL 以外の一意インデックス値が変更された場合、そのイベントを削除イベントと挿入イベントに分割します。詳細については、 ドキュメントを参照してください。
• tidb_remove_orderby_in_subqueryのデフォルト値をOFFからONに変更します。これは、オプティマイザが不要なソート操作を回避するために、サブクエリからORDER BY句を削除することを意味します。この変更により、クエリ結果の行の順序が変わる可能性があります。ISO/IEC SQL 標準では、クエリ結果がサブクエリで指定されたORDER BYソートに従うことを要求していません。最終結果で特定の順序を確保する必要がある場合は、外側のクエリにORDER BY句を追加します。アプリケーションがサブクエリのソートに依存している場合は、この変数をOFFに設定できます。以前のバージョンからアップグレードされたクラスターは、デフォルトでは以前の動作を維持します。

システム変数

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

改善点

• TiDB

  • インデックススキャン範囲の構築ロジックを最適化し、複雑な条件をインデックススキャン範囲に変換することをサポートする#41572 #44389 @xuyifangreeneyes
  • 新しい監視メトリクスStale Read OPSとStale Read Trafficを追加 #43325 @you06
  • 古い読み取りの再試行リーダーがロックに遭遇した場合、TiDB はロックを解決した後、リーダーで強制的に再試行します。これにより、不要なオーバーヘッドが回避されます。 #43659 @you06
  • 推定時間を使用して古い読み取りtsを計算し、古い読み取りのオーバーヘッドを削減します #44215 @you06
  • 長時間実行されるトランザクションのログとシステム変数を追加する #41471 @crazycs520
  • 圧縮されたMySQLプロトコルを介したTiDBへの接続をサポートします。これにより、低帯域幅ネットワーク下でのデータ集約型クエリのパフォーマンスが向上し、帯域幅コストが削減されます。これはzlibとzstdベースの圧縮の両方をサポートします。 #22605 @dveeden
  • utf8とutf8bm3の両方を従来の 3 バイト UTF-8 文字セットエンコーディングとして認識することで、従来の UTF-8 エンコーディングを持つテーブルを MySQL 8.0 から TiDB に移行しやすくなります。 #26226 @dveeden
  • :=ステートメントでの代入にUPDATEを使用するサポート #44751 @CbcWestwolf

• TiKV

  • pd.retry-intervalを使用した接続要求失敗などのシナリオで PD 接続の再試行間隔を設定することをサポートします #14964 @rleungx
  • グローバルなリソース使用状況を組み込むことで、リソース制御スケジューリングアルゴリズムを最適化する #14604 @Connor1996
  • check_leaderリクエストに gzip 圧縮を使用してトラフィックを削減します #14553 @you06
  • check_leaderリクエストに関連するメトリクスを追加 #14658 @you06
  • TiKVが書き込みコマンドを処理する際の詳細な時間情報を提供する #12362 @cfzjywxk

• PD

  • PDリーダー選出には別のgRPC接続を使用して、他のリクエストの影響を防ぐ #6403 @rleungx
  • マルチリージョンのシナリオにおけるホットスポットの問題を軽減するために、デフォルトでバケット分割を有効にします #6433 @bufferflies

• ツール

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

    • Azure Blob Storage への共有アクセス署名 (SAS) によるアクセスをサポート #44199 @Leavrth

  • TiCDC

    • オブジェクトstorageサービスへのレプリケーションシナリオでDDL操作が発生した場合に、データファイルが格納されるディレクトリの構造を最適化する #8891 @CharlesCheung96
    • KafkaへのレプリケーションシナリオにおけるOAUTHBEARER認証のサポート #8865 @Rustin170506
    • Kafka #9143 @3AceShowHandショーハンドにレプリケーションシナリオのDELETEオペレーションのハンドルキーのみを出力するオプションを追加

  • TiDBデータ移行（DM）

    • MySQL 8.0 で圧縮バイナリログを増分レプリケーションのデータソースとして読み込むことをサポートする #6381 @dveeden

  • TiDB Lightning

    • リーダー切り替えによるエラーを回避するため、インポート時の再試行メカニズムを最適化する #44263 @lance6716
    • インポート後にSQLでチェックサムを検証して検証の安定性を向上させる #41941 @GMHDBJD
    • 幅の広いテーブルをインポートする際のTiDB Lightning OOM の問題の最適化 #43853 @D3Hunter

バグ修正

• TiDB

  • CTE を使用したクエリによって TiDB がハングする問題を修正#43749 #36896 @guo-shaoge
  • min, maxクエリ結果が正しくない問題を修正 #43805 @wshwsh12
  • SHOW PROCESSLISTステートメントで、サブクエリ時間が長いステートメントのトランザクションの TxnStart が表示されない問題を修正します #40851 @crazycs520
  • コプロセッサータスクにTxnScopeがないため、古いデータの読み取りグローバル最適化が有効にならない問題を修正します #43365 @you06
  • フォロワー読み取りが再試行前にフラッシュバックエラーを処理しないためクエリエラーが発生する問題を修正します #43673 @you06
  • ON UPDATEステートメントが主キーを正しく更新しない場合にデータとインデックスが不整合になる問題を修正 #44565 @zyguan
  • 権限テーブルの一部の列における大文字小文字の区別に関する問題を修正しました #41048 @bb7133
  • UNIX_TIMESTAMP()関数の上限を3001-01-19 03:14:07.999999 UTCに変更し、MySQL 8.0.28 以降のバージョンと整合性を取る #43987 @YangKeao
  • インジェストモードでインデックスの追加が失敗する問題を修正 #44137 @tangenta
  • ロールバック状態のDDLタスクをキャンセルすると、関連するメタデータにエラーが発生する問題を修正しました #44143 @wjhuang2016
  • memTrackerをカーソルフェッチで使用するとメモリリークが発生する問題を修正 #44254 @YangKeao
  • データベースを削除するとGCの進行が遅くなる問題を修正 #33069 @tiancaiamao
  • インデックス結合のプローブフェーズでパーティションテーブル内の対応する行が見つからない場合に TiDB がエラーを返す問題を修正 #43686 @AilinKid@mjonss
  • SUBPARTITIONを使用してパーティションテーブルを作成する際に警告が表示されない問題を修正#41198 #41200 @mjonss
  • MAX_EXECUTION_TIMEを超えるクエリが強制終了された場合、返されるエラーメッセージが MySQL のエラーメッセージと一致しない問題を修正します。 #43031 @dveeden
  • LEADINGヒントがブロックエイリアスのクエリをサポートしていない問題を修正 #44645 @qw4990
  • LAST_INSERT_ID()関数の戻り値の型を VARCHAR から LONGLONG に変更し、MySQL の戻り値の型と一致させます #44574 @Defined2014
  • 相関のないサブクエリを含むステートメントで共通テーブル式（CTE）を使用すると、誤った結果が返される可能性がある問題を修正しました #44051 @winoros
  • 結合したテーブルの再配置によって不正な外部結合結果が生じる可能性がある問題を修正 #44314 @AilinKid
  • PREPARE stmt FROM "ANALYZE TABLE xxx"がtidb_mem_quota_queryによって強制終了される可能性がある問題を修正 #44320 @chrysan

• TiKV

  • TiKVが古い悲観的ロックの競合を処理する際にトランザクションが誤った値を返す問題を修正 #13298 @cfzjywxk
  • インメモリ悲観的ロックがフラッシュバックの失敗やデータの不整合を引き起こす可能性がある問題を修正 #13303 @JmPotato
  • TiKVが古いリクエストを処理する際にフェアロックが正しくない可能性がある問題を修正 #13298 @cfzjywxk
  • autocommitとpoint get replica readが線形化可能性を損なう可能性がある問題を修正 #14715 @cfzjywxk

• PD

  • 特定の特殊なケースで冗長レプリカが自動的に修復されない問題を修正 #6573 @nolouch

• TiFlash

  • 結合構築側のデータが非常に大きく、小さな文字列型の列が多数含まれている場合、クエリが必要以上にメモリを消費する可能性がある問題を修正します #7416 @yibin87

• ツール

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

    • checksum mismatchが一部のケースで誤って報告される問題を修正 #44472 @Leavrth
    • resolved lock timeoutが一部のケースで誤って報告される問題を修正 #43236 @YuJuncen
    • 統計情報の復元時に TiDB がpanic可能性がある問題を修正 #44490 @tangenta

  • TiCDC

    • 解決済みTSが一部のケースで正しく進まない問題を修正 #8963 @CharlesCheung96
    • Avro または CSV プロトコルが使用されている場合、 UPDATEオペレーションが古い値を出力できない問題を修正 #9086 @3AceShowHand
    • Kafkaへのデータ複製時にダウンストリームメタデータを頻繁に読み取ることで発生する、ダウンストリームへの過剰な負荷の問題を修正します #8959 @Rustin170506
    • TiDBまたはMySQLへのデータ複製時に、下流の双方向レプリケーション関連変数を頻繁に設定することで発生する、下流ログが多すぎる問題を修正しました #9180 @asddongmen
    • PDノードのクラッシュによってTiCDCノードが再起動する問題を修正 #8868 @asddongmen
    • TiCDCが下流のKafka-on-Pulsarで変更フィードを作成できない問題を修正 #8892 @Rustin170506

  • TiDB Lightning

    • experimental.allow-expression-indexが有効でデフォルト値がUUIDの場合に発生するTiDB Lightningpanic問題を修正 #44497 @lichunzhu
    • データファイルの分割中にタスクが終了した際に発生するTiDB Lightningpanicの問題を修正 #43195 @lance6716

寄稿者

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

• asjdf
• ブラックティア23
• キャヴァンスー
• ダラエス
• デモマニト
• dhysum
• ハッピーv587
• ジフハスト
• L-メープル
• ニュリク
• SeigeC
• タンジンユ97