From f396e6994c1bc42b7502f338f74e2b9572981d48 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 14:36:40 +0900 Subject: [PATCH 1/5] =?UTF-8?q?i18n(ja):=20unify=20=E3=82=AA=E3=83=97?= =?UTF-8?q?=E3=83=86=E3=82=A3=E3=83=9E=E3=82=A4=E3=82=B6=E3=83=BC=20to=20?= =?UTF-8?q?=E3=82=AA=E3=83=97=E3=83=86=E3=82=A3=E3=83=9E=E3=82=A4=E3=82=B6?= =?UTF-8?q?=20(no=20long=20vowel=20mark)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Direction decided 2026-07-24/08-04: オプティマイザ (no ー) matches the dominant corpus form and optimizer-hints.md's own H1. Fresh recount: 592 no-vowel vs 259 with-vowel (~70/30). Mechanical substring replace, verified 0 remaining オプティマイザー and no double-vowel artifacts. 116 files, 259 occurrences. --- TOC-tidb-cloud-essential.md | 2 +- TOC-tidb-cloud-premium.md | 2 +- TOC-tidb-cloud-starter.md | 2 +- TOC-tidb-cloud.md | 2 +- TOC.md | 2 +- agg-distinct-optimization.md | 4 +-- analyze-slow-queries.md | 12 ++++---- benchmark/benchmark-tidb-using-ch.md | 2 +- ...v4.0-performance-benchmarking-with-tpch.md | 2 +- .../index-management-best-practices.md | 4 +-- .../multi-column-index-best-practices.md | 12 ++++---- comment-syntax.md | 4 +-- control-execution-plan.md | 2 +- ddl_embedded_analyze.md | 2 +- derive-topn-from-window.md | 4 +-- .../dev-guide-hybrid-oltp-and-olap-queries.md | 2 +- develop/dev-guide-index-best-practice.md | 6 ++-- develop/dev-guide-join-tables.md | 2 +- explain-index-merge.md | 4 +-- explain-indexes.md | 2 +- explain-joins.md | 2 +- extended-statistics.md | 10 +++---- faq/sql-faq.md | 4 +-- functions-and-operators/tidb-functions.md | 2 +- generated-columns.md | 2 +- .../information-schema-tiflash-replica.md | 2 +- optimizer-fix-controls.md | 14 +++++----- optimizer-hints.md | 16 +++++------ quick-start-with-htap.md | 2 +- releases/release-1.0-ga.md | 2 +- releases/release-1.1-alpha.md | 4 +-- releases/release-2.0-ga.md | 6 ++-- releases/release-2.0-rc.1.md | 2 +- releases/release-2.0.4.md | 2 +- releases/release-2.1-beta.md | 6 ++-- releases/release-2.1-ga.md | 4 +-- releases/release-2.1-rc.1.md | 4 +-- releases/release-2.1-rc.2.md | 4 +-- releases/release-2.1-rc.3.md | 4 +-- releases/release-2.1-rc.4.md | 4 +-- releases/release-2.1-rc.5.md | 6 ++-- releases/release-2.1.1.md | 6 ++-- releases/release-2.1.16.md | 4 +-- releases/release-2.1.17.md | 4 +-- releases/release-2.1.18.md | 4 +-- releases/release-2.1.19.md | 4 +-- releases/release-2.1.3.md | 6 ++-- releases/release-2.1.4.md | 4 +-- releases/release-2.1.5.md | 6 ++-- releases/release-2.1.6.md | 6 ++-- releases/release-3.0-beta.md | 8 +++--- releases/release-3.0-ga.md | 4 +-- releases/release-3.0.0-beta.1.md | 6 ++-- releases/release-3.0.0-rc.1.md | 4 +-- releases/release-3.0.0-rc.2.md | 4 +-- releases/release-3.0.0-rc.3.md | 6 ++-- releases/release-3.0.2.md | 6 ++-- releases/release-3.0.3.md | 4 +-- releases/release-3.0.4.md | 2 +- releases/release-3.0.5.md | 4 +-- releases/release-3.0.6.md | 4 +-- releases/release-3.0.8.md | 4 +-- releases/release-3.1.0-beta.md | 4 +-- releases/release-5.0.0-rc.md | 4 +-- releases/release-6.1.0.md | 2 +- releases/release-6.1.1.md | 2 +- releases/release-6.3.0.md | 2 +- releases/release-6.4.0.md | 2 +- releases/release-6.5.0.md | 8 +++--- releases/release-6.5.10.md | 2 +- releases/release-6.6.0.md | 4 +-- releases/release-7.0.0.md | 4 +-- releases/release-7.1.0.md | 6 ++-- releases/release-7.1.6.md | 2 +- releases/release-7.2.0.md | 4 +-- releases/release-7.4.0.md | 2 +- releases/release-7.5.3.md | 2 +- releases/release-7.6.0.md | 2 +- releases/release-8.0.0.md | 4 +-- releases/release-8.1.1.md | 2 +- releases/release-8.4.0.md | 2 +- releases/release-pre-ga.md | 4 +-- releases/release-rc.1.md | 4 +-- releases/release-rc.2.md | 8 +++--- releases/release-rc.3.md | 4 +-- releases/release-rc.4.md | 6 ++-- sql-non-prepared-plan-cache.md | 2 +- sql-physical-optimization.md | 2 +- sql-plan-management.md | 12 ++++---- sql-plan-replayer.md | 4 +-- sql-prepared-plan-cache.md | 4 +-- sql-statements/sql-statement-alter-index.md | 6 ++-- sql-statements/sql-statement-select.md | 2 +- sql-statements/sql-statement-set-variable.md | 2 +- sql-tuning-best-practice.md | 28 +++++++++---------- subquery-optimization.md | 2 +- system-variable-reference.md | 2 +- system-variables.md | 8 +++--- tidb-cloud/releases/release-notes-2022.md | 2 +- tidb-cloud/serverless-faqs.md | 2 +- tidb-cloud/tidb-cloud-htap-quickstart.md | 4 +-- tidb-cloud/tidb-cloud-sql-tuning-overview.md | 2 +- ...v6.5-performance-benchmarking-with-tpcc.md | 2 +- ...v7.1-performance-benchmarking-with-tpcc.md | 2 +- ...v7.5-performance-benchmarking-with-tpcc.md | 2 +- ...v8.1-performance-benchmarking-with-tpcc.md | 2 +- ...v8.5-performance-benchmarking-with-tpcc.md | 2 +- tidb-performance-tuning-config.md | 2 +- tiflash-performance-tuning-methods.md | 4 +-- tiflash/tiflash-late-materialization.md | 2 +- tiflash/tiflash-overview.md | 2 +- tiflash/tune-tiflash-performance.md | 2 +- tiflash/use-tidb-to-read-tiflash.md | 4 +-- tiflash/use-tiflash-mpp-mode.md | 6 ++-- tiup/tiup-bench.md | 2 +- wrong-index-solution.md | 14 +++++----- 116 files changed, 247 insertions(+), 247 deletions(-) diff --git a/TOC-tidb-cloud-essential.md b/TOC-tidb-cloud-essential.md index 570e8710f26c0..55fe8332881e0 100644 --- a/TOC-tidb-cloud-essential.md +++ b/TOC-tidb-cloud-essential.md @@ -112,7 +112,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザー修正コントロール](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） diff --git a/TOC-tidb-cloud-premium.md b/TOC-tidb-cloud-premium.md index d0de3df477a2f..307dadfa4d2fd 100644 --- a/TOC-tidb-cloud-premium.md +++ b/TOC-tidb-cloud-premium.md @@ -110,7 +110,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザー修正コントロール](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) diff --git a/TOC-tidb-cloud-starter.md b/TOC-tidb-cloud-starter.md index 5a173bee3e6b0..329ea48b00a4f 100644 --- a/TOC-tidb-cloud-starter.md +++ b/TOC-tidb-cloud-starter.md @@ -106,7 +106,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザー修正コントロール](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） diff --git a/TOC-tidb-cloud.md b/TOC-tidb-cloud.md index 7abe9303ccd5b..25029852f8109 100644 --- a/TOC-tidb-cloud.md +++ b/TOC-tidb-cloud.md @@ -125,7 +125,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザー修正コントロール](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [インデックスアドバイザー](/index-advisor.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) diff --git a/TOC.md b/TOC.md index 8263d50441982..e146affb1e844 100644 --- a/TOC.md +++ b/TOC.md @@ -296,7 +296,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザー修正コントロール](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [インデックスアドバイザー](/index-advisor.md) - チュートリアル - [1つのリージョンに複数の可用性ゾーンを展開](/multi-data-centers-in-one-city-deployment.md) diff --git a/agg-distinct-optimization.md b/agg-distinct-optimization.md index 1fd1d54fc12bb..555d0879ab9a8 100644 --- a/agg-distinct-optimization.md +++ b/agg-distinct-optimization.md @@ -1,11 +1,11 @@ --- title: Distinct Optimization -summary: TiDB クエリ オプティマイザーに distinct` 最適化を導入します。 +summary: TiDB クエリ オプティマイザに distinct` 最適化を導入します。 --- # クエリの最適化 {#distinct-optimization} -このドキュメントでは、集計関数の`SELECT DISTINCT`と`DISTINCT`含む、TiDB クエリ オプティマイザーの`distinct`最適化について説明します。 +このドキュメントでは、集計関数の`SELECT DISTINCT`と`DISTINCT`含む、TiDB クエリ オプティマイザの`distinct`最適化について説明します。 ## `SELECT`文の`DISTINCT`修飾子 {#distinct-modifier-in-select-statements} diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md index 1686dd0e007ff..600cecf851caf 100644 --- a/analyze-slow-queries.md +++ b/analyze-slow-queries.md @@ -16,8 +16,8 @@ summary: スロークエリを見つけて分析する方法を学びます。 一般的に、クエリが遅くなる主な原因は次のとおりです。 -- 間違ったインデックスが選択された、間違った結合タイプまたはシーケンスが選択されたなどのオプティマイザーの問題。 -- システムの問題。オプティマイザーが原因ではない問題はすべてシステムの問題です。例えば、TiKVインスタンスがビジー状態だとリクエストの処理が遅くなったり、リージョン情報が古くなるとクエリが遅くなったりします。 +- 間違ったインデックスが選択された、間違った結合タイプまたはシーケンスが選択されたなどのオプティマイザの問題。 +- システムの問題。オプティマイザが原因ではない問題はすべてシステムの問題です。例えば、TiKVインスタンスがビジー状態だとリクエストの処理が遅くなったり、リージョン情報が古くなるとクエリが遅くなったりします。 実際の状況では、オプティマイザの問題がシステムの問題を引き起こす可能性があります。例えば、特定の種類のクエリでは、オプティマイザはインデックスではなくフルテーブルスキャンを使用します。その結果、SQLクエリが多くのリソースを消費し、一部のTiKVインスタンスのCPU使用率が急上昇します。これはシステムの問題のように見えますが、実際にはオプティマイザの問題です。 @@ -25,7 +25,7 @@ summary: スロークエリを見つけて分析する方法を学びます。 1. クエリのパフォーマンスのボトルネック、つまりクエリ プロセスの中で時間のかかる部分を特定します。 2. システムの問題を分析します。クエリのボトルネックとその時点の監視/ログ情報に基づいて、考えられる原因を分析します。 -3. オプティマイザーの問題を分析します。より優れた実行計画があるかどうかを分析します。 +3. オプティマイザの問題を分析します。より優れた実行計画があるかどうかを分析します。 上記の手順については、次のセクションで説明します。 @@ -165,7 +165,7 @@ mysql> explain analyze select count(*) from t where a=(select max(t1.a) from t t TiDBの実行計画は正しいものの、実行速度が遅い場合を考えてみましょう。このような問題を解決するには、SQL文の`EXPLAIN ANALYZE`の結果に応じてパラメータを調整するか、ヒントを使用します。 -実行計画が正しくない場合は、セクション[オプティマイザーの問題を分析する](#analyze-optimizer-issues)を参照してください。 +実行計画が正しくない場合は、セクション[オプティマイザの問題を分析する](#analyze-optimizer-issues)を参照してください。 #### 同時実行性が低い {#low-concurrency} @@ -234,7 +234,7 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a; +------------------------------+-------------+-----------+---------------+---------------------------------------------------------+ ``` -## オプティマイザーの問題を分析する {#analyze-optimizer-issues} +## オプティマイザの問題を分析する {#analyze-optimizer-issues} オプティマイザの問題を分析するには、実行計画が妥当かどうかを判断する必要があります。最適化プロセスと各演算子についてある程度の理解が必要です。 @@ -248,7 +248,7 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a; 上記の例は、データ読み取りに使用される演算子です。その他の演算子については、 [TiDB実行計画を理解する](/explain-overview.md)を参照してください。 -さらに、 [SQLチューニングの概要](/sql-tuning-overview.md)読むことで、TiDB オプティマイザーをより深く理解し、実行計画が妥当かどうかを判断するのに役立ちます。 +さらに、 [SQLチューニングの概要](/sql-tuning-overview.md)読むことで、TiDB オプティマイザをより深く理解し、実行計画が妥当かどうかを判断するのに役立ちます。 オプティマイザに関する問題のほとんどは[SQLチューニングの概要](/sql-tuning-overview.md)で説明されています。解決策については、以下のドキュメントを参照してください。 diff --git a/benchmark/benchmark-tidb-using-ch.md b/benchmark/benchmark-tidb-using-ch.md index d2b944ebbb528..8dafb650f33a6 100644 --- a/benchmark/benchmark-tidb-using-ch.md +++ b/benchmark/benchmark-tidb-using-ch.md @@ -9,7 +9,7 @@ summary: TiDB で CH-benCHmark テストを実行する方法を学びます。 CH-benCHmarkは、テスト[TPC-C](http://www.tpc.org/tpcc/)とテスト[TPC-H](http://www.tpc.org/tpch/)両方を含む混合ワークロードです。HTAPシステムのテストで最も一般的なワークロードです。詳細については、 [混合ワークロードCH-benCHmark](https://dl.acm.org/doi/10.1145/1988842.1988850)を参照してください。 -CH-benCHmarkテストを実行する前に、まずTiDBのHTAPコンポーネントである[TiFlash](/tiflash/tiflash-overview.md)導入する必要があります。TiFlashと[TiFlashレプリカを作成する](#create-tiflash-replicas)TiFlashすると、TiKVがTPC-Cオンライントランザクションの最新データをTiFlashにリアルタイムで複製し、TiDBオプティマイザーがTPC-HワークロードからTiFlashのMPPエンジンにOLAPクエリを自動的にプッシュダウンして効率的に実行します。 +CH-benCHmarkテストを実行する前に、まずTiDBのHTAPコンポーネントである[TiFlash](/tiflash/tiflash-overview.md)導入する必要があります。TiFlashと[TiFlashレプリカを作成する](#create-tiflash-replicas)TiFlashすると、TiKVがTPC-Cオンライントランザクションの最新データをTiFlashにリアルタイムで複製し、TiDBオプティマイザがTPC-HワークロードからTiFlashのMPPエンジンにOLAPクエリを自動的にプッシュダウンして効率的に実行します。 このドキュメントのCH-benCHmarkテストは[ゴーTPC](https://github.com/pingcap/go-tpc)に基づいて実装されています。テストプログラムは以下の[TiUP](/tiup/tiup-overview.md)のコマンドでダウンロードできます。 diff --git a/benchmark/v4.0-performance-benchmarking-with-tpch.md b/benchmark/v4.0-performance-benchmarking-with-tpch.md index 781b0920fe684..bd4fac0214bc6 100644 --- a/benchmark/v4.0-performance-benchmarking-with-tpch.md +++ b/benchmark/v4.0-performance-benchmarking-with-tpch.md @@ -187,6 +187,6 @@ set global tidb_index_lookup_join_concurrency = 16; 結果の説明: - **v4.0 TiKV Onlyは**、TiDBがTiKVからのみデータを読み取ることを意味します。結果は、TiDBとTiKVをv4.0にアップグレードした後、TPC-Hパフォーマンスが向上したことを示しています。 -- **v4.0 TiKV/ TiFlash Automatically は**、TiDB オプティマイザーがコスト見積もりに基づいてTiFlashレプリカからデータを読み取るかどうかを自動的に決定することを意味します。この結果は、v4.0 の完全な HTAP 形式で TPC-H パフォーマンスが向上したことを示しています。 +- **v4.0 TiKV/ TiFlash Automatically は**、TiDB オプティマイザがコスト見積もりに基づいてTiFlashレプリカからデータを読み取るかどうかを自動的に決定することを意味します。この結果は、v4.0 の完全な HTAP 形式で TPC-H パフォーマンスが向上したことを示しています。 上の図から、22 のクエリ セット全体で TPC-H のパフォーマンスが平均で約 100% 向上することがわかります。 diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index 7718bbb1b9161..aa1b59c8d6f23 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -8,8 +8,8 @@ aliases: ['/ja/tidb/stable/index-management-best-practices/'] インデックスは、データベースクエリのパフォーマンスを最適化し、大量のデータのスキャンの必要性を減らすために不可欠です。しかし、アプリケーションの進化、ビジネスロジックの変化、データ量の増加に伴い、元のインデックス設計では以下のような問題が発生することがあります。 -- 未使用のインデックス: これらのインデックスはかつては関連していましたが、クエリ オプティマイザーによって選択されなくなり、ストレージを消費し、書き込み操作に不要なオーバーヘッドが追加されます。 -- 非効率的なインデックス: 一部のインデックスはオプティマイザーによって使用されますが、予想よりも多くのデータをスキャンするため、ディスク I/O が増加し、クエリのパフォーマンスが低下します。 +- 未使用のインデックス: これらのインデックスはかつては関連していましたが、クエリ オプティマイザによって選択されなくなり、ストレージを消費し、書き込み操作に不要なオーバーヘッドが追加されます。 +- 非効率的なインデックス: 一部のインデックスはオプティマイザによって使用されますが、予想よりも多くのデータをスキャンするため、ディスク I/O が増加し、クエリのパフォーマンスが低下します。 これらのインデックス作成の問題を放置すると、ストレージコストの増加、パフォーマンスの低下、運用効率の低下につながる可能性があります。TiDBのような分散SQLデータベースでは、分散クエリの規模と複数ノード間の調整の複雑さにより、インデックス作成の非効率性の影響はさらに大きくなります。そのため、データベースを最適化した状態に保つには、定期的なインデックス監査が不可欠です。 diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index c4ae62d3da920..27c61bb270f4d 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -8,7 +8,7 @@ aliases: ['/ja/tidb/stable/multi-column-index-best-practices/'] 今日のデータドリブンの世界では、大規模データセットに対する複雑なクエリを効率的に処理することが、アプリケーションの応答性とパフォーマンスを維持するために不可欠です。大規模かつ高負荷の環境を管理するために設計された分散SQLデータベースであるTiDBでは、データアクセスパスの最適化がスムーズで効率的なクエリの実行に不可欠です。 -インデックスは、テーブル内のすべての行をスキャンする必要性を回避し、クエリパフォーマンスを向上させる強力なツールです。TiDBのクエリオプティマイザーは、複数列のインデックスを活用してデータをインテリジェントにフィルタリングし、MySQLなどの従来のデータベースでは効率的に処理できない複雑なクエリ条件を処理します。 +インデックスは、テーブル内のすべての行をスキャンする必要性を回避し、クエリパフォーマンスを向上させる強力なツールです。TiDBのクエリオプティマイザは、複数列のインデックスを活用してデータをインテリジェントにフィルタリングし、MySQLなどの従来のデータベースでは効率的に処理できない複雑なクエリ条件を処理します。 このドキュメントでは、マルチカラムインデックスの仕組み、その重要性、そしてTiDBの最適化によって複雑なクエリ条件が効率的なアクセスパスに変換される仕組みについて解説します。最適化を行うことで、大規模な環境でもレスポンスの高速化、テーブルスキャンの最小化、そしてパフォーマンスの合理化を実現できます。 @@ -17,7 +17,7 @@ aliases: ['/ja/tidb/stable/multi-column-index-best-practices/'] ## 前提条件 {#prerequisites} - マルチ列インデックス機能は、TiDB v8.3 以降のバージョンで使用できます。 -- この機能を使用する前に、 [オプティマイザー修正制御**54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 +- この機能を使用する前に、 [オプティマイザ修正制御**54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 ## 背景: 複数列インデックス {#background-multi-column-indexes} @@ -187,7 +187,7 @@ EXPLAIN FORMAT = "brief" +-------------------------+------+--------------------------------------------------------------------+------------------------------------------------------------+ ``` -重複に基づいて結合された範囲または個別の範囲を作成することにより、オプティマイザーは`OR`条件に対してインデックスを効率的に使用し、不要なスキャンを回避してクエリのパフォーマンスを向上させることができます。 +重複に基づいて結合された範囲または個別の範囲を作成することにより、オプティマイザは`OR`条件に対してインデックスを効率的に使用し、不要なスキャンを回避してクエリのパフォーマンスを向上させることができます。 ## 複数列インデックスの結合条件（ `AND`条件） {#conjunctive-conditions-and-conditions-in-multi-column-indexes} @@ -212,11 +212,11 @@ CREATE TABLE t1 ( (a1, b1) > (1, 10) AND (a1, b1) < (10, 20) ``` -このクエリでは複数の列を比較するため、TiDB オプティマイザーは次の2つの手順で処理する必要があります。 +このクエリでは複数の列を比較するため、TiDB オプティマイザは次の2つの手順で処理する必要があります。 1. 表現を翻訳します。 - TiDB オプティマイザーは、これらの複雑な条件をより単純な部分に分解します。 + TiDB オプティマイザは、これらの複雑な条件をより単純な部分に分解します。 - `(a1, b1) > (1, 10)`は`(a1 > 1) OR (a1 = 1 AND b1 > 10)`に変換されます。つまり、 `a1` `1`より大きい場合、または`a1`がちょうど`1`で`b1`が`10`より大きい場合がすべて含まれます。 - `(a1, b1) < (10, 20)`は`(a1 < 10) OR (a1 = 10 AND b1 < 20)`に変換され、 `a1` `10`より小さい場合や、 `a1`がちょうど`10`で`b1`が`20`より小さい場合をカバーします。 @@ -259,7 +259,7 @@ EXPLAIN FORMAT = "brief" この例では、テーブルには約5億行あります。しかし、この最適化により、TiDBはアクセスを約4,000行、つまり全データのわずか0.0008%に絞り込むことができます。この改良により、クエリのレイテンシーは、最適化を行わない場合の2分以上から数ミリ秒へと大幅に短縮されます。 -このような条件で完全なテーブルスキャンを必要とする MySQL とは異なり、TiDB オプティマイザーはこれらの派生範囲を活用して複雑な行式を効率的に処理できます。 +このような条件で完全なテーブルスキャンを必要とする MySQL とは異なり、TiDB オプティマイザはこれらの派生範囲を活用して複雑な行式を効率的に処理できます。 ## 結論 {#conclusion} diff --git a/comment-syntax.md b/comment-syntax.md index f7837e92282d9..7b755ee5c5b4f 100644 --- a/comment-syntax.md +++ b/comment-syntax.md @@ -127,13 +127,13 @@ TiDB には独自のコメント構文 (つまり、TiDB 固有のコメント ## オプティマイザコメント構文 {#optimizer-comment-syntax} -別の種類のコメントは、オプティマイザーヒントとして特別に扱われます。 +別の種類のコメントは、オプティマイザヒントとして特別に扱われます。 ```sql SELECT /*+ hint */ FROM ...; ``` -TiDB がサポートするオプティマイザヒントの詳細については、 [オプティマイザーヒント](/optimizer-hints.md)を参照してください。 +TiDB がサポートするオプティマイザヒントの詳細については、 [オプティマイザヒント](/optimizer-hints.md)を参照してください。 > **Note:** > diff --git a/control-execution-plan.md b/control-execution-plan.md index 56b9b8ea8a93e..56986bbdd97f3 100644 --- a/control-execution-plan.md +++ b/control-execution-plan.md @@ -11,4 +11,4 @@ SQLチューニングの最初の2章では、TiDBの実行計画の理解方法 - しかし、ヒントはSQL文を侵襲的に変更します。場合によっては、ヒントを単純に挿入することはできません。SQL [SQLプラン管理](/sql-plan-management.md)では、TiDBが別の構文を使用して実行計画の生成を非侵襲的に制御する方法と、バックグラウンドで実行計画を自動的に進化させる方法について説明しています。この方法は、バージョンアップグレードやクラスタのパフォーマンス低下によって引き起こされる実行計画の不安定性などの問題に対処するのに役立ちます。 - 最後に、[最適化ルールと式のプッシュダウンのブロックリスト](/blocklist-control-plan.md)でブロックリストの使用方法を学びます。 -上記の方法に加えて、実行計画はいくつかのシステム変数にも影響されます。システムレベルまたはセッションレベルでこれらの変数を変更することで、実行計画の生成を制御できます。v6.5.3およびv7.1.0以降、TiDBは比較的特殊な変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)を導入しました。この変数は複数の制御項目を受け入れることができ、クラスタのアップグレード後にオプティマイザの動作変更によって発生するパフォーマンスの低下を防ぐために、オプティマイザの動作をよりきめ細かく制御できます。詳細については[オプティマイザー修正コントロール](/optimizer-fix-controls.md)を参照してください。 +上記の方法に加えて、実行計画はいくつかのシステム変数にも影響されます。システムレベルまたはセッションレベルでこれらの変数を変更することで、実行計画の生成を制御できます。v6.5.3およびv7.1.0以降、TiDBは比較的特殊な変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)を導入しました。この変数は複数の制御項目を受け入れることができ、クラスタのアップグレード後にオプティマイザの動作変更によって発生するパフォーマンスの低下を防ぐために、オプティマイザの動作をよりきめ細かく制御できます。詳細については[オプティマイザ修正コントロール](/optimizer-fix-controls.md)を参照してください。 diff --git a/ddl_embedded_analyze.md b/ddl_embedded_analyze.md index 94604c9d32dd1..83c803d2148b8 100644 --- a/ddl_embedded_analyze.md +++ b/ddl_embedded_analyze.md @@ -14,7 +14,7 @@ summary: このドキュメントでは、新しく作成または再編成さ ## 使用シナリオ {#usage-scenarios} -DDL操作によってインデックスが交互に追加または変更されるシナリオでは、新しいインデックスに統計情報がないため、既存の安定したクエリに推定バイアスが生じ、オプティマイザーが最適ではないプランを選択する可能性があります。詳細については、 [問題 #57948](https://github.com/pingcap/tidb/issues/57948)を参照してください。 +DDL操作によってインデックスが交互に追加または変更されるシナリオでは、新しいインデックスに統計情報がないため、既存の安定したクエリに推定バイアスが生じ、オプティマイザが最適ではないプランを選択する可能性があります。詳細については、 [問題 #57948](https://github.com/pingcap/tidb/issues/57948)を参照してください。 例えば： diff --git a/derive-topn-from-window.md b/derive-topn-from-window.md index 4befd20f36480..63b5bebba1696 100644 --- a/derive-topn-from-window.md +++ b/derive-topn-from-window.md @@ -63,7 +63,7 @@ EXPLAIN SELECT * FROM (SELECT ROW_NUMBER() OVER () AS rownumber FROM t) dt WHERE +----------------------------------+---------+-----------+---------------+-----------------------------------------------------------------------+ ``` -このクエリでは、オプティマイザーはウィンドウ関数から Limit 演算子を導出し、それを TiKV にプッシュダウンします。 +このクエリでは、オプティマイザはウィンドウ関数から Limit 演算子を導出し、それを TiKV にプッシュダウンします。 #### 例2: ORDER BYを使用したウィンドウ関数 {#example-2-window-functions-with-order-by} @@ -89,7 +89,7 @@ EXPLAIN SELECT * FROM (SELECT ROW_NUMBER() OVER (ORDER BY value) AS rownumber FR +----------------------------------+----------+-----------+---------------+---------------------------------------------------------------------------------------------+ ``` -このクエリでは、オプティマイザーはウィンドウ関数から TopN 演算子を導出し、それを TiKV にプッシュダウンします。 +このクエリでは、オプティマイザはウィンドウ関数から TopN 演算子を導出し、それを TiKV にプッシュダウンします。 ### PARTITION BYを使用したウィンドウ関数 {#window-functions-with-partition-by} diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index df17a71fe7152..2a2708a6c7337 100644 --- a/develop/dev-guide-hybrid-oltp-and-olap-queries.md +++ b/develop/dev-guide-hybrid-oltp-and-olap-queries.md @@ -210,7 +210,7 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'bookshop' ### クエリエンジンを指定する {#specify-a-query-engine} -TiDBはコストベースオプティマイザー（CBO）を使用して、コスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に選択します。ただし、クエリがトランザクションクエリか分析クエリかが明確な場合は、 [オプティマイザヒント](/optimizer-hints.md)を使用して使用するクエリエンジンを指定できます。 +TiDBはコストベースオプティマイザ（CBO）を使用して、コスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に選択します。ただし、クエリがトランザクションクエリか分析クエリかが明確な場合は、 [オプティマイザヒント](/optimizer-hints.md)を使用して使用するクエリエンジンを指定できます。 クエリで使用するエンジンを指定するには、次のステートメントのように`/*+ read_from_storage(engine_name[table_name]) */`ヒントを使用できます。 diff --git a/develop/dev-guide-index-best-practice.md b/develop/dev-guide-index-best-practice.md index 81bbe56ed0b56..9f9202915e937 100644 --- a/develop/dev-guide-index-best-practice.md +++ b/develop/dev-guide-index-best-practice.md @@ -63,7 +63,7 @@ CREATE TABLE `books` ( SELECT * FROM books WHERE published_at = '2018-08-18 21:42:08'; ``` -- クエリの条件としてインデックス列を使用する場合は、計算、関数、または型変換を使用しないでください。そうしないと、TiDB オプティマイザーがインデックスを使用できなくなります。 +- クエリの条件としてインデックス列を使用する場合は、計算、関数、または型変換を使用しないでください。そうしないと、TiDB オプティマイザがインデックスを使用できなくなります。 時間型列`published_at`に新しいインデックスを作成するとします。 @@ -121,9 +121,9 @@ CREATE TABLE `books` ( SELECT * FROM books WHERE title LIKE '%database'; ``` -- クエリ条件に複数のインデックスがあり、実際にどのインデックスが最適かわかっている場合は、 [オプティマイザーヒント](/optimizer-hints.md)を指定してTiDBオプティマイザにそのインデックスを強制的に使用させることをお勧めします。これにより、統計情報の不正確さやその他の問題により、TiDBオプティマイザが誤ったインデックスを選択することを防ぐことができます。 +- クエリ条件に複数のインデックスがあり、実際にどのインデックスが最適かわかっている場合は、 [オプティマイザヒント](/optimizer-hints.md)を指定してTiDBオプティマイザにそのインデックスを強制的に使用させることをお勧めします。これにより、統計情報の不正確さやその他の問題により、TiDBオプティマイザが誤ったインデックスを選択することを防ぐことができます。 - 次のクエリでは、インデックス`id_idx`と`title_idx`がそれぞれ列`id`と`title`で使用可能であると仮定し、 `id_idx`の方が適していることが分かっている場合は、SQL で`USE INDEX`ヒントを使用して、TiDB オプティマイザーに`id_idx`インデックスを使用するように強制できます。 + 次のクエリでは、インデックス`id_idx`と`title_idx`がそれぞれ列`id`と`title`で使用可能であると仮定し、 `id_idx`の方が適していることが分かっている場合は、SQL で`USE INDEX`ヒントを使用して、TiDB オプティマイザに`id_idx`インデックスを使用するように強制できます。 ```sql SELECT * FROM t USE INDEX(id_idx) WHERE id = 1 and title = 'database'; diff --git a/develop/dev-guide-join-tables.md b/develop/dev-guide-join-tables.md index d595b8d618f29..839ab686b7485 100644 --- a/develop/dev-guide-join-tables.md +++ b/develop/dev-guide-join-tables.md @@ -216,7 +216,7 @@ TiDB は、次の一般的なテーブル結合アルゴリズムをサポート オプティマイザは、結合対象テーブルのデータ量などの要因に基づいて、適切な結合アルゴリズムを選択します。クエリが結合にどのアルゴリズムを使用しているかは、 `EXPLAIN`ステートメントで確認できます。 -TiDB のオプティマイザーが最適な結合アルゴリズムに従って実行されない場合は、 [オプティマイザヒント](/optimizer-hints.md)を使用して、TiDB がより適切な結合アルゴリズムを使用するように強制できます。 +TiDB のオプティマイザが最適な結合アルゴリズムに従って実行されない場合は、 [オプティマイザヒント](/optimizer-hints.md)を使用して、TiDB がより適切な結合アルゴリズムを使用するように強制できます。 例えば、上記の左結合クエリの例が、オプティマイザによって選択されないハッシュ結合アルゴリズムを使用した方が高速に実行されると仮定すると、キーワード`SELECT`の後にヒント`/*+ HASH_JOIN(b, r) */`を追加できます。テーブルに別名がある場合は、ヒントでも別名を使用することに注意してください。 diff --git a/explain-index-merge.md b/explain-index-merge.md index a79a032401bb3..4f2cdc1ec962d 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -76,7 +76,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t, idx_a, idx_b, idx_c) */ * FROM t WHERE a > +-------------------------------+---------+-----------+-------------------------+------------------------------------------------+ ``` -上の例から、フィルター条件は`AND`コネクタとして使用する`WHERE`句であることがわかります。インデックスマージが有効になる前は、オプティマイザーは3つのインデックス（ `idx_a` 、 `idx_b` 、または`idx_c` ）のうち1つしか選択できません。 +上の例から、フィルター条件は`AND`コネクタとして使用する`WHERE`句であることがわかります。インデックスマージが有効になる前は、オプティマイザは3つのインデックス（ `idx_a` 、 `idx_b` 、または`idx_c` ）のうち1つしか選択できません。 フィルタ条件のいずれかの選択性が低い場合、オプティマイザは対応するインデックスを直接選択し、理想的な実行効率を実現します。ただし、データ分布が以下の3つの条件をすべて満たす場合は、交差型インデックスマージの使用を検討できます。 @@ -92,7 +92,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t, idx_a, idx_b, idx_c) */ * FROM t WHERE a > > > - SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用すると、 `tidb_enable_index_merge`設定に関係なく、オプティマイザにインデックスマージを強制的に適用させることができます。フィルタリング条件にプッシュダウンできない式が含まれている場合にインデックスマージを有効にするには、SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用する必要があります。 > -> - [オプティマイザー修正制御 52869](/optimizer-fix-controls.md#52869-new-in-v810)が`OFF`に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式（フルテーブルスキャン以外）を選択できるとき、オプティマイザはインデックスマージを自動的には選択しません。インデックスマージを使用するには、オプティマイザヒントを指定する必要があります。v8.5.7以降、この制御のデフォルト値は`ON`に変更されており、これにより前述の制限がデフォルトで解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できるようになります。 +> - [オプティマイザ修正制御 52869](/optimizer-fix-controls.md#52869-new-in-v810)が`OFF`に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式（フルテーブルスキャン以外）を選択できるとき、オプティマイザはインデックスマージを自動的には選択しません。インデックスマージを使用するには、オプティマイザヒントを指定する必要があります。v8.5.7以降、この制御のデフォルト値は`ON`に変更されており、これにより前述の制限がデフォルトで解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できるようになります。 > > - 現時点では、インデックスマージは[一時テーブル](/temporary-tables.md)ではサポートされていません。 > diff --git a/explain-indexes.md b/explain-indexes.md index 14a4a891a9ea9..cedef0fa8dc44 100644 --- a/explain-indexes.md +++ b/explain-indexes.md @@ -92,7 +92,7 @@ EXPLAIN SELECT * FROM t1 WHERE intkey >= 99 AND intkey <= 103; - `├─IndexRangeScan_8(Build)`演算子は`intkey`インデックスの範囲スキャンを実行し、内部の`RowID` (このテーブルの場合は主キー) の値を取得します。 - 次に、 `└─TableRowIDScan_9(Probe)`演算子はテーブルデータから完全な行を取得します。 -`IndexLookup`タスクには2つのステップが必要なため、多数の行が一致するシナリオでは、SQLオプティマイザーは[統計](/statistics.md)に基づいて`TableFullScan`演算子を選択する可能性があります。次の例では、多数の行が`intkey > 100`条件に一致するため、 `TableFullScan`が選択されます。 +`IndexLookup`タスクには2つのステップが必要なため、多数の行が一致するシナリオでは、SQLオプティマイザは[統計](/statistics.md)に基づいて`TableFullScan`演算子を選択する可能性があります。次の例では、多数の行が`intkey > 100`条件に一致するため、 `TableFullScan`が選択されます。 ```sql EXPLAIN SELECT * FROM t1 WHERE intkey > 100; diff --git a/explain-joins.md b/explain-joins.md index c7258762c5ea2..7edfecfd8c29a 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -68,7 +68,7 @@ SELECT * FROM t1 INNER JOIN t2 ON t1.id=t2.t1_id WHERE t1.pad1 = 'value' and t2. 内部結合操作において、TiDBは結合順序の変更を実装しており、最初に`t1`または`t2`にアクセスする可能性があります。TiDBがステップ`build`を適用する最初のテーブルとしてテーブル`t1`を選択し、その後、テーブル`t2`をプローブする前に述語`t1.pad1 = 'value'`でフィルタリングできると仮定します。述語`t2.pad1='value'`のフィルタはテーブル`t2`の各プローブに適用されるため、他の結合方法よりも効率が低下する可能性があります。 -インデックス結合は、ビルド側が小さく、プローブ側が事前にインデックス化されていて大きい場合に効果的です。次のクエリでは、インデックス結合のパフォーマンスはハッシュ結合よりも低く、SQLオプティマイザーによって選択されません。 +インデックス結合は、ビルド側が小さく、プローブ側が事前にインデックス化されていて大きい場合に効果的です。次のクエリでは、インデックス結合のパフォーマンスはハッシュ結合よりも低く、SQLオプティマイザによって選択されません。 ```sql -- DROP previously added index diff --git a/extended-statistics.md b/extended-statistics.md index ccddd099baee7..e06d2fc17f3fd 100644 --- a/extended-statistics.md +++ b/extended-statistics.md @@ -1,6 +1,6 @@ --- title: Introduction to Extended Statistics -summary: 拡張統計を使用してオプティマイザーをガイドする方法を学習します。 +summary: 拡張統計を使用してオプティマイザをガイドする方法を学習します。 --- # 拡張統計入門 {#introduction-to-extended-statistics} @@ -8,7 +8,7 @@ summary: 拡張統計を使用してオプティマイザーをガイドする TiDBは以下の2種類の統計情報を収集できます。このドキュメントでは、拡張統計を使用してオプティマイザをガイドする方法について説明します。このドキュメントを読む前に、まず[統計入門](/statistics.md)を読むことをお勧めします。 - 基本統計：ヒストグラムやCount-Min Sketchなど、主に個々の列に焦点を当てた統計。これらは、オプティマイザがクエリコストを見積もるために不可欠です。詳細は[統計入門](/statistics.md)をご覧ください。 -- 拡張統計: 指定された列間のデータの相関関係に焦点を当てた統計。クエリされた列が相関している場合に、オプティマイザーがクエリ コストをより正確に見積もることを可能にします。 +- 拡張統計: 指定された列間のデータの相関関係に焦点を当てた統計。クエリされた列が相関している場合に、オプティマイザがクエリ コストをより正確に見積もることを可能にします。 `ANALYZE`の文が手動または自動で実行される場合、TiDB はデフォルトで基本統計のみを収集し、拡張統計は収集しません。これは、拡張統計は特定のシナリオにおけるオプティマイザの推定にのみ使用され、収集には追加のオーバーヘッドが必要になるためです。 @@ -127,12 +127,12 @@ CREATE TABLE t(col1 INT, col2 INT, KEY(col1), KEY(col2)); SELECT * FROM t WHERE col1 > 1 ORDER BY col2 LIMIT 1; ``` -上記のクエリを実行する場合、TiDB オプティマイザーにはテーブル`t`にアクセスするための次のオプションがあります。 +上記のクエリを実行する場合、TiDB オプティマイザにはテーブル`t`にアクセスするための次のオプションがあります。 - `col1`のインデックスを使用してテーブル`t`にアクセスし、結果を`col2`でソートして`Top-1`を計算します。 - `col2`のインデックスを使用して、 `col1 > 1`満たす最初の行を検索します。このアクセス方法のコストは、TiDBが`col2`の順序でテーブルをスキャンする際に、どれだけの行がフィルタリングされるかに主に依存します。 -拡張統計がない場合、TiDB オプティマイザーは`col1`と`col2`が独立していると想定するだけなので、**大きな推定誤差が生じます**。 +拡張統計がない場合、TiDB オプティマイザは`col1`と`col2`が独立していると想定するだけなので、**大きな推定誤差が生じます**。 ### ステップ3. 拡張統計を有効にする {#step-3-enable-extended-statistics} @@ -146,7 +146,7 @@ ALTER TABLE t ADD STATS_EXTENDED s1 correlation(col1, col2); ### ステップ4. 拡張統計がどのように違いを生むかを確認する {#step-4-see-how-extended-statistics-make-a-difference} -TiDB が相関関係の拡張統計を取得すると、オプティマイザーはスキャンする行数をより正確に見積もることができます。 +TiDB が相関関係の拡張統計を取得すると、オプティマイザはスキャンする行数をより正確に見積もることができます。 この時点で、 [ステージ2. 拡張統計なしでサンプルクエリを実行する](#step-2-execute-an-example-query-without-extended-statistics)のクエリでは、 `col1`と`col2`厳密に順序付けされています。TiDBが`col2`のインデックスを使用してテーブル`t`にアクセスし、 `col1 > 1`満たす最初の行を検索すると、TiDBオプティマイザは行数推定を次のクエリに変換します。 diff --git a/faq/sql-faq.md b/faq/sql-faq.md index b436cee6b3aaa..3df334d86463c 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -229,11 +229,11 @@ TiDBは、 [グローバル](/system-variables.md#tidb_force_priority)単位ま テーブル内の行数またはパーティションテーブルの単一パーティションの行数が 1000 に達し、テーブルまたはパーティションの比率 (変更された行数 / 現在の行の合計数) が[`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio)超えると、 [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md)ステートメントが自動的にトリガーされます。 -システム変数`tidb_auto_analyze_ratio`のデフォルト値は`0.5`で、この機能がデフォルトで有効になっていることを示します。システム変数`tidb_auto_analyze_ratio`を[`pseudo-estimate-ratio`](/tidb-configuration-file.md#pseudo-estimate-ratio)以上（デフォルト値は`0.8` ）に設定することは推奨されません。そうしないと、オプティマイザーが疑似統計を使用する可能性があります。TiDB v5.3.0 では[`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-new-in-v530)変数が導入され、これを`OFF`に設定すると、統計が古くても疑似統計は使用されません。 +システム変数`tidb_auto_analyze_ratio`のデフォルト値は`0.5`で、この機能がデフォルトで有効になっていることを示します。システム変数`tidb_auto_analyze_ratio`を[`pseudo-estimate-ratio`](/tidb-configuration-file.md#pseudo-estimate-ratio)以上（デフォルト値は`0.8` ）に設定することは推奨されません。そうしないと、オプティマイザが疑似統計を使用する可能性があります。TiDB v5.3.0 では[`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-new-in-v530)変数が導入され、これを`OFF`に設定すると、統計が古くても疑似統計は使用されません。 `auto analyze`無効にするには、システム変数[`tidb_enable_auto_analyze`](/system-variables.md#tidb_enable_auto_analyze-new-in-v610)を使用します。 -## オプティマイザーヒントを使用してオプティマイザーの動作をオーバーライドできますか? {#can-i-use-optimizer-hints-to-override-the-optimizer-behavior} +## オプティマイザヒントを使用してオプティマイザの動作をオーバーライドできますか? {#can-i-use-optimizer-hints-to-override-the-optimizer-behavior} TiDBは、 [ヒント](/optimizer-hints.md)と[SQLプラン管理](/sql-plan-management.md)を含む、デフォルトのクエリオプティマイザの動作をオーバーライドする複数の方法をサポートしています。基本的な使用方法はMySQLと同様ですが、TiDB固有の拡張機能がいくつかあります。 diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index cc309705c21fd..4f641197c7ea3 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -510,7 +510,7 @@ SELECT *, TIDB_ROW_CHECKSUM() FROM t WHERE id = 1; - `WHERE`サブクエリでは使用できません。 - 整数フィールドのみの一意インデックスを分散させるために使用できます。 - 複合インデックスでは効果がない可能性があります。 - - FastPlan プロセスを実行できないため、オプティマイザーのパフォーマンスに影響します。 + - FastPlan プロセスを実行できないため、オプティマイザのパフォーマンスに影響します。 - プリペアドプランキャッシュには使用できません。 次の例は、 `TIDB_SHARD()`関数の使用方法を示しています。 diff --git a/generated-columns.md b/generated-columns.md index ff007571afab3..dacf0cc40735c 100644 --- a/generated-columns.md +++ b/generated-columns.md @@ -92,7 +92,7 @@ ERROR 1048 (23000): Column 'city' cannot be null ## 生成列インデックスの置換ルール {#generated-columns-index-replacement-rule} -クエリ内の式がインデックス付きの生成列と厳密に同等である場合、TiDB は式を対応する生成列に置き換え、実行計画の構築時にオプティマイザーがそのインデックスを考慮できるようにします。 +クエリ内の式がインデックス付きの生成列と厳密に同等である場合、TiDB は式を対応する生成列に置き換え、実行計画の構築時にオプティマイザがそのインデックスを考慮できるようにします。 次の例では、式`a+1`に対して生成列を作成し、インデックスを追加します。列`a`の型はint、列`a+1`の型はbigintです。生成列の型がintに設定されている場合、置換は行われません。型変換ルールについては、 [式評価の型変換](/functions-and-operators/type-conversion-in-expression-evaluation.md)を参照してください。 diff --git a/information-schema/information-schema-tiflash-replica.md b/information-schema/information-schema-tiflash-replica.md index ae4e7828297ac..7eedd9d69dddb 100644 --- a/information-schema/information-schema-tiflash-replica.md +++ b/information-schema/information-schema-tiflash-replica.md @@ -36,5 +36,5 @@ DESC TIFLASH_REPLICA; - `TABLE_ID` : テーブルの内部 ID。TiDB クラスター内で一意です。 - `REPLICA_COUNT` : TiFlashレプリカの数。 - `LOCATION_LABELS` : TiFlashレプリカが作成されるときに設定される LocationLabelList。 -- `AVAILABLE` : テーブルのTiFlashレプリカが利用可能かどうかを示します。値が`1` （利用可能）の場合、TiDB オプティマイザーはクエリコストに基づいて、クエリを TiKV またはTiFlashにプッシュダウンするかをインテリジェントに選択します。値が`0` （利用不可）の場合、TiDB はクエリをTiFlashにプッシュダウンしません。このフィールドの値が`1` （利用可能）になると、それ以上変化しなくなります。 +- `AVAILABLE` : テーブルのTiFlashレプリカが利用可能かどうかを示します。値が`1` （利用可能）の場合、TiDB オプティマイザはクエリコストに基づいて、クエリを TiKV またはTiFlashにプッシュダウンするかをインテリジェントに選択します。値が`0` （利用不可）の場合、TiDB はクエリをTiFlashにプッシュダウンしません。このフィールドの値が`1` （利用可能）になると、それ以上変化しなくなります。 - `PROGRESS` : TiFlashレプリカのレプリケーションの進行状況。小数点以下2桁の精度で分単位です。このフィールドのスコープは`[0, 1]`です。`AVAILABLE`が`1`で`PROGRESS`が1未満の場合、 TiFlashレプリカはTiKVより大幅に遅れており、データレプリケーションの待機タイムアウトにより、 TiFlashにプッシュダウンされたクエリは失敗する可能性があります。 diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index 70ece37304ffa..5f573f44c60e3 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -1,9 +1,9 @@ --- title: Optimizer Fix Controls -summary: オプティマイザー修正制御機能について学習し、tidb_opt_fix_control` を使用して TiDB オプティマイザーをより細かく制御する方法について説明します。 +summary: オプティマイザ修正制御機能について学習し、tidb_opt_fix_control` を使用して TiDB オプティマイザをより細かく制御する方法について説明します。 --- -# オプティマイザー修正コントロール {#optimizer-fix-controls} +# オプティマイザ修正コントロール {#optimizer-fix-controls} 製品が継続的に進化するにつれて、TiDBオプティマイザの動作が変化し、より合理的な実行計画が生成されます。しかし、特定のシナリオでは、新しい動作が予期しない結果につながる可能性があります。例えば、 @@ -14,9 +14,9 @@ summary: オプティマイザー修正制御機能について学習し、tidb_ ## `tidb_opt_fix_control`の紹介 {#introduction-to-tidb-opt-fix-control} -v6.5.3 および v7.1.0 以降、TiDB は、オプティマイザーの動作をより細かく制御するための[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を提供します。 +v6.5.3 および v7.1.0 以降、TiDB は、オプティマイザの動作をより細かく制御するための[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を提供します。 -各修正は、特定の目的のためにTiDBオプティマイザーの動作を調整するために用いられる制御項目です。修正には、動作変更の技術的な詳細が記載されたGitHub Issueに対応する番号が付けられています。例えば、修正`44262`の場合、修正[問題44262](https://github.com/pingcap/tidb/issues/44262)でその制御内容を確認できます。 +各修正は、特定の目的のためにTiDBオプティマイザの動作を調整するために用いられる制御項目です。修正には、動作変更の技術的な詳細が記載されたGitHub Issueに対応する番号が付けられています。例えば、修正`44262`の場合、修正[問題44262](https://github.com/pingcap/tidb/issues/44262)でその制御内容を確認できます。 システム変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) 、複数の修正をカンマ区切りで 1つの値として受け入れます ( `,` )。形式は`"<#issue1>:,<#issue2>:,...,<#issueN>:"`で、 `<#issueN>`修正番号です。例: @@ -24,7 +24,7 @@ v6.5.3 および v7.1.0 以降、TiDB は、オプティマイザーの動作を SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; ``` -## オプティマイザー修正コントロールリファレンス {#optimizer-fix-controls-reference} +## オプティマイザ修正コントロールリファレンス {#optimizer-fix-controls-reference} ### `33031`バージョン8.0.0の新機能 {#33031-new-in-v800} @@ -81,7 +81,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `ON` 。v8.5.0 より前では、デフォルト値は`OFF`です。 - 可能`OFF`値: `ON` -- この変数は、強制されていないプランを見つけた後、クエリの最適化中にオプティマイザーが強制されているプランを探索するかどうかを制御します。 +- この変数は、強制されていないプランを見つけた後、クエリの最適化中にオプティマイザが強制されているプランを探索するかどうかを制御します。 ### `47400`バージョン8.4.0の新機能 {#47400-new-in-v840} @@ -113,7 +113,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `OFF` - 可能`OFF`値: `ON` - 現在、TiDBオプティマイザは、各接続詞が範囲のリストで構成される複雑な接続詞条件のインデックス範囲の導出に制限があります。これは、一般的な範囲交差を適用することで解決できます。 -- この修正コントロールを有効にすると、この制限が解除され、オプティマイザーは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 +- この修正コントロールを有効にすると、この制限が解除され、オプティマイザは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 ### `56318` {#56318} diff --git a/optimizer-hints.md b/optimizer-hints.md index f20946ded4393..85b297fec9225 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -186,7 +186,7 @@ SELECT /*+ HASH_JOIN_PROBE(t2) */ * FROM t1, t2 WHERE t1.id = t2.id; 同様に、実行計画でインデックス結合が選択されている場合、準結合クエリは駆動テーブルとして外部クエリのみを使用できます。この場合、サブクエリの結果が外部クエリの結果よりも小さい場合、実行速度が予想よりも遅くなる可能性があります。 -`SEMI_JOIN_REWRITE()`を使用してクエリを書き換えると、オプティマイザーは選択範囲を拡張して、より適切な実行計画を選択できます。 +`SEMI_JOIN_REWRITE()`を使用してクエリを書き換えると、オプティマイザは選択範囲を拡張して、より適切な実行計画を選択できます。 ```sql -- Does not use SEMI_JOIN_REWRITE() to rewrite the query. @@ -256,7 +256,7 @@ SELECT /*+ BROADCAST_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; `NO_DECORRELATE()`ヒントは、指定されたクエリブロック内の相関サブクエリに対して、相関解除を実行しないようにオプティマイザに指示します。このヒントは`EXISTS` 、 `IN` 、 `ANY` 、 `ALL` 、 `SOME`サブクエリ、および相関列を含むスカラーサブクエリ（つまり、相関サブクエリ）に適用されます。 -このヒントがクエリブロック内で使用される場合、オプティマイザーはサブクエリとその外側のクエリブロック間の相関列の非相関化を試行せず、常に Apply 演算子を使用してクエリを実行します。 +このヒントがクエリブロック内で使用される場合、オプティマイザはサブクエリとその外側のクエリブロック間の相関列の非相関化を試行せず、常に Apply 演算子を使用してクエリを実行します。 デフォルトでは、TiDBは相関サブクエリに対して[相関除去を実行する](/correlated-subquery-optimization.md)ことで実行効率を高めようとします。しかし、 [いくつかのシナリオ](/correlated-subquery-optimization.md#restrictions)では、相関除去によって実行効率が低下する可能性があります。このような場合は、このヒントを使用してオプティマイザに相関除去を行わないよう手動で指示することができます。例えば、次のようになります。 @@ -534,7 +534,7 @@ select /*+ READ_FROM_STORAGE(TIFLASH[t1], TIKV[t2]) */ t1.a from t t1, t t2 wher SELECT /*+ USE_INDEX_MERGE(t1, idx_a, idx_b, idx_c) */ * FROM t1 WHERE t1.a > 10 OR t1.b > 10; ``` -同じテーブルに複数の`USE_INDEX_MERGE`ヒントが指定されている場合、オプティマイザーはこれらのヒントによって指定されたインデックス セットの結合からインデックスを選択しようとします。 +同じテーブルに複数の`USE_INDEX_MERGE`ヒントが指定されている場合、オプティマイザはこれらのヒントによって指定されたインデックス セットの結合からインデックスを選択しようとします。 > **Note:** > @@ -555,7 +555,7 @@ SELECT /*+ LEADING(t1, t2) */ * FROM t1, t2, t3 WHERE t1.id = t2.id and t2.id = - `LEADING`ヒントが複数指定されています。 - `LEADING`ヒントで指定されたテーブル名が存在しません。 - `LEADING`ヒントに重複したテーブル名が指定されています。 -- オプティマイザーは、ヒント`LEADING`で指定された順序に従って結合操作を実行できません。 +- オプティマイザは、ヒント`LEADING`で指定された順序に従って結合操作を実行できません。 - `straight_join()`ヒントがすでに存在します。 - クエリには、外部結合とデカルト積が含まれています。 @@ -772,7 +772,7 @@ select /*+ READ_CONSISTENT_REPLICA() */ * from t; ### IGNORE_PLAN_CACHE() {#ignore_plan_cache} -`IGNORE_PLAN_CACHE()`ヒントは、現在の`prepare`ステートメントを処理するときにプランキャッシュを使用しないようにオプティマイザーに通知します。 +`IGNORE_PLAN_CACHE()`ヒントは、現在の`prepare`ステートメントを処理するときにプランキャッシュを使用しないようにオプティマイザに通知します。 このヒントは、 [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)有効な場合に、特定の種類のクエリのプランキャッシュを一時的に無効にするために使用されます。 @@ -817,7 +817,7 @@ SELECT @@MAX_EXECUTION_TIME; ### STRAIGHT_JOIN() {#straight_join} -`STRAIGHT_JOIN()`ヒントは、結合プランを生成するときに、 `FROM`句のテーブル名の順序でテーブルを結合するようにオプティマイザーに通知します。 +`STRAIGHT_JOIN()`ヒントは、結合プランを生成するときに、 `FROM`句のテーブル名の順序でテーブルを結合するようにオプティマイザに通知します。 ```sql SELECT /*+ STRAIGHT_JOIN() */ * FROM t t1, t t2 WHERE t1.a = t2.a; @@ -830,7 +830,7 @@ SELECT /*+ STRAIGHT_JOIN() */ * FROM t t1, t t2 WHERE t1.a = t2.a; ### NTH_PLAN(N) {#nth_plann} -ヒント`NTH_PLAN(N)`は、物理的な最適化中に見つかった`N`番目の物理プランを選択するようにオプティマイザーに通知します。`N`は正の整数である必要があります。 +ヒント`NTH_PLAN(N)`は、物理的な最適化中に見つかった`N`番目の物理プランを選択するようにオプティマイザに通知します。`N`は正の整数である必要があります。 指定された`N`が物理最適化の検索範囲を超える場合、TiDB は警告を返し、このヒントを無視する戦略に基づいて最適な物理プランを選択します。 @@ -940,7 +940,7 @@ SHOW WARNINGS; #### `INL_JOIN`ヒントは、テーブル結合の列に組み込み関数が使用されている場合には効果がありません。 {#inl_join-hint-does-not-take-effect-when-built-in-functions-are-used-on-columns-for-joining-tables} -場合によっては、テーブルを結合する列で組み込み関数を使用すると、オプティマイザーが`IndexJoin`プランを選択できず、 `INL_JOIN`ヒントも有効にならないことがあります。 +場合によっては、テーブルを結合する列で組み込み関数を使用すると、オプティマイザが`IndexJoin`プランを選択できず、 `INL_JOIN`ヒントも有効にならないことがあります。 たとえば、次のクエリは、テーブルの結合に使われる列`tname`で組み込み関数`substr`を使用します。 diff --git a/quick-start-with-htap.md b/quick-start-with-htap.md index 0f3baca3beef7..6bac0812c0923 100644 --- a/quick-start-with-htap.md +++ b/quick-start-with-htap.md @@ -155,7 +155,7 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and もう一度[ステップ3](#step-3-query-data-with-the-row-based-storage-engine)の SQL 文を実行すると、 TiDB HTAPのパフォーマンスを確認できます。 -TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。TiFlashが選択されているかどうかを確認するには、 `desc`または`explain analyze`ステートメントを使用します。例： +TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。TiFlashが選択されているかどうかを確認するには、 `desc`または`explain analyze`ステートメントを使用します。例： ```sql USE test; diff --git a/releases/release-1.0-ga.md b/releases/release-1.0-ga.md index d495a2a99b312..575e2ee4fef64 100644 --- a/releases/release-1.0-ga.md +++ b/releases/release-1.0-ga.md @@ -9,7 +9,7 @@ summary: TiDB 1.0は、MySQLとの互換性、SQLの最適化、安定性、そ ## TiDB {#tidb} -- SQL クエリ オプティマイザー: +- SQL クエリ オプティマイザ: - コストモデルを調整する - プッシュダウンを分析する - 関数シグネチャプッシュダウン diff --git a/releases/release-1.1-alpha.md b/releases/release-1.1-alpha.md index 00fa5cd816927..dd9549da045d0 100644 --- a/releases/release-1.1-alpha.md +++ b/releases/release-1.1-alpha.md @@ -1,6 +1,6 @@ --- title: TiDB 1.1 Alpha Release Notes -summary: 2018年1月19日にリリースされたTiDB 1.1 Alphaでは、MySQLとの互換性、SQLの最適化、安定性、パフォーマンスが大幅に向上しています。主なアップデートには、SQLパーサー、クエリオプティマイザー、エグゼキューターの強化、およびPROXYプロトコルのサーバーサポートが含まれます。PDではAPIの追加、TLSサポート、スケジューリングの改善が提供される一方、TiKVではRaft学習器のサポート、TLS、パフォーマンス最適化が導入されています。さらに、データリカバリツールの強化とフロー制御メカニズムの改善も行われています。 +summary: 2018年1月19日にリリースされたTiDB 1.1 Alphaでは、MySQLとの互換性、SQLの最適化、安定性、パフォーマンスが大幅に向上しています。主なアップデートには、SQLパーサー、クエリオプティマイザ、エグゼキューターの強化、およびPROXYプロトコルのサーバーサポートが含まれます。PDではAPIの追加、TLSサポート、スケジューリングの改善が提供される一方、TiKVではRaft学習器のサポート、TLS、パフォーマンス最適化が導入されています。さらに、データリカバリツールの強化とフロー制御メカニズムの改善も行われています。 --- # TiDB 1.1 アルファ リリースノート {#tidb-1-1-alpha-release-notes} @@ -11,7 +11,7 @@ summary: 2018年1月19日にリリースされたTiDB 1.1 Alphaでは、MySQLと - SQLパーサー - より多くの構文をサポート -- SQLクエリオプティマイザー +- SQLクエリオプティマイザ - よりコンパクトな構造を使用して、統計情報のメモリ使用量を削減します - tidb-server の起動時に統計情報の読み込みを高速化 - より正確なクエリコスト評価を提供する diff --git a/releases/release-2.0-ga.md b/releases/release-2.0-ga.md index 2fc4155b6397a..52666c39ff496 100644 --- a/releases/release-2.0-ga.md +++ b/releases/release-2.0-ga.md @@ -1,15 +1,15 @@ --- title: TiDB 2.0 Release Notes -summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの互換性、SQLオプティマイザー、エグゼキューター、そして安定性が向上しました。主なアップデートには、メモリ使用量を削減するコンパクトなデータ構造、空のGROUP BY句に対応するStream 集計演算子、そしてより多くのMySQL構文のサポートが含まれます。TiKV機能には、リージョン Merge`、`Raw DeleteRange` API、そして`ReadPool`を使用した読み取りパフォーマンスの向上が含まれます。TiSpark 1.0 GAは、Apache Sparkを使用したTiDBデータの分散コンピューティングを提供し、gRPC通信フレームワーク、計算プッシュダウン、インデックス関連のサポート、コストベースの最適化、そして複数のSparkインターフェースをサポートします。 +summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの互換性、SQLオプティマイザ、エグゼキューター、そして安定性が向上しました。主なアップデートには、メモリ使用量を削減するコンパクトなデータ構造、空のGROUP BY句に対応するStream 集計演算子、そしてより多くのMySQL構文のサポートが含まれます。TiKV機能には、リージョン Merge`、`Raw DeleteRange` API、そして`ReadPool`を使用した読み取りパフォーマンスの向上が含まれます。TiSpark 1.0 GAは、Apache Sparkを使用したTiDBデータの分散コンピューティングを提供し、gRPC通信フレームワーク、計算プッシュダウン、インデックス関連のサポート、コストベースの最適化、そして複数のSparkインターフェースをサポートします。 --- # TiDB 2.0 リリースノート {#tidb-2-0-release-notes} -2018 年 4月 27日に、TiDB 2.0 GA がリリースされました。TiDB 1.0 と比較して、このリリースでは、MySQL 互換性、SQL オプティマイザー、エグゼキューター、安定性が大幅に向上しています。 +2018 年 4月 27日に、TiDB 2.0 GA がリリースされました。TiDB 1.0 と比較して、このリリースでは、MySQL 互換性、SQL オプティマイザ、エグゼキューター、安定性が大幅に向上しています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - よりコンパクトなデータ構造を使用して、統計情報のメモリ使用量を削減します。 - tidb-server プロセスを起動するときに統計情報の読み込みを高速化します - 統計情報の動的な更新をサポート [実験的] diff --git a/releases/release-2.0-rc.1.md b/releases/release-2.0-rc.1.md index 942dbd77ea1d2..2b2856ca518a2 100644 --- a/releases/release-2.0-rc.1.md +++ b/releases/release-2.0-rc.1.md @@ -1,6 +1,6 @@ --- title: TiDB 2.0 RC1 Release Notes -summary: 2018年3月9日にリリースされたTiDB 2.0 RC1では、MySQLとの互換性、SQLの最適化、そして安定性が向上しています。主なアップデートには、SQL文のメモリ使用量制限、Stream Aggregate演算子のサポート、設定ファイルの検証、設定情報用のHTTP APIなどがあります。また、TiDBはMySQL構文の互換性、オプティマイザー、ブールフィールドの長さも強化しています。PDではロジックとパフォーマンスの最適化が行われ、TiKVではgRPC呼び出しの修正とメトリクス用のgRPC APIの追加が行われました。さらに、TiKVはSSDの使用状況をチェックし、読み取りパフォーマンスを最適化し、メトリクスの使用状況を改善しました。 +summary: 2018年3月9日にリリースされたTiDB 2.0 RC1では、MySQLとの互換性、SQLの最適化、そして安定性が向上しています。主なアップデートには、SQL文のメモリ使用量制限、Stream Aggregate演算子のサポート、設定ファイルの検証、設定情報用のHTTP APIなどがあります。また、TiDBはMySQL構文の互換性、オプティマイザ、ブールフィールドの長さも強化しています。PDではロジックとパフォーマンスの最適化が行われ、TiKVではgRPC呼び出しの修正とメトリクス用のgRPC APIの追加が行われました。さらに、TiKVはSSDの使用状況をチェックし、読み取りパフォーマンスを最適化し、メトリクスの使用状況を改善しました。 --- # TiDB 2.0 RC1 リリースノート {#tidb-2-0-rc1-release-notes} diff --git a/releases/release-2.0.4.md b/releases/release-2.0.4.md index 2e75c276fa5e1..5ab178a1ebe9f 100644 --- a/releases/release-2.0.4.md +++ b/releases/release-2.0.4.md @@ -15,7 +15,7 @@ summary: TiDB 2.0.4は2018年6月15日にリリースされ、システムの互 - クエリコストの見積り精度を最適化する - gRPCの`backoff max delay`のパラメータを設定する - 構成ファイル内の単一のステートメントのメモリしきい値の構成をサポート -- オプティマイザーのエラーをリファクタリングする +- オプティマイザのエラーをリファクタリングする - `Cast Decimal`データの副作用を修正 - 特定のシナリオで`Merge Join`演算子の誤った結果の問題を修正しました - Nullオブジェクトを文字列に変換する問題を修正 diff --git a/releases/release-2.1-beta.md b/releases/release-2.1-beta.md index 3c83f3d32ed1e..3f36b4fa28911 100644 --- a/releases/release-2.1-beta.md +++ b/releases/release-2.1-beta.md @@ -1,15 +1,15 @@ --- title: TiDB 2.1 Beta Release Notes -summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイザー、統計情報、実行エンジンの改善が含まれています。MySQL構文のサポートが拡大し、メモリ使用量が削減され、DDLおよびDML文が最適化されています。PDはRaft PreVoteの有効化、スケジューラー問題の最適化、メトリクスの追加を行いました。TiKVはRustのアップグレード、メトリクスの追加、パフォーマンスの向上を行いました。互換性に関する注意事項として、新バージョンではv2.0.xへのロールバックがサポートされないこと、およびRaft Learnerがデフォルトで有効化されることなどが挙げられます。 +summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイザ、統計情報、実行エンジンの改善が含まれています。MySQL構文のサポートが拡大し、メモリ使用量が削減され、DDLおよびDML文が最適化されています。PDはRaft PreVoteの有効化、スケジューラー問題の最適化、メトリクスの追加を行いました。TiKVはRustのアップグレード、メトリクスの追加、パフォーマンスの向上を行いました。互換性に関する注意事項として、新バージョンではv2.0.xへのロールバックがサポートされないこと、およびRaft Learnerがデフォルトで有効化されることなどが挙げられます。 --- # TiDB 2.1 ベータ版リリースノート {#tidb-2-1-beta-release-notes} -2018 年 6月 29日に、TiDB 2.1 ベータ版がリリースされました。TiDB 2.0 と比較して、このリリースでは安定性、SQL オプティマイザー、統計情報、実行エンジンが大幅に改善されています。 +2018 年 6月 29日に、TiDB 2.1 ベータ版がリリースされました。TiDB 2.0 と比較して、このリリースでは安定性、SQL オプティマイザ、統計情報、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - 実行パフォーマンスを向上させるために、選択範囲`Index Join`を最適化します。 - 相関サブクエリを最適化し、 `Filter`プッシュダウンし、インデックス範囲を拡張して、一部のクエリの効率を桁違いに向上させます。 - `UPDATE`と`DELETE`ステートメントの`Index Hint`と`Join Hint`をサポートする diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index ee2e10d7a3755..70a230279a443 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1 GA Release Notes -summary: TiDB 2.1 GA は 2018年 11月 30日にリリースされ、安定性、パフォーマンス、互換性、および使いやすさが大幅に向上しました。このリリースには、SQL オプティマイザー、SQL エグゼキューター、統計、式、サーバー、DDL、互換性、Placement Driver(PD)、TiKV、およびツールの最適化が含まれています。また、高速なフルデータインポートを実現するTiDB Lightningが導入されています。ただし、TiDB 2.1 では、新しいストレージエンジンの採用により、v2.0.x 以前へのダウングレードはサポートされていません。さらに、TiDB 2.1 では並列 DDL が有効になっているため、バージョン 2.0.1 より前の TiDB を使用しているクラスターは、ローリングアップデートを使用して 2.1 にアップグレードできません。TiDB 2.0.6 以前から TiDB 2.1 にアップグレードする場合、進行中の DDL 操作によってアップグレードプロセスが遅くなる可能性があります。 +summary: TiDB 2.1 GA は 2018年 11月 30日にリリースされ、安定性、パフォーマンス、互換性、および使いやすさが大幅に向上しました。このリリースには、SQL オプティマイザ、SQL エグゼキューター、統計、式、サーバー、DDL、互換性、Placement Driver(PD)、TiKV、およびツールの最適化が含まれています。また、高速なフルデータインポートを実現するTiDB Lightningが導入されています。ただし、TiDB 2.1 では、新しいストレージエンジンの採用により、v2.0.x 以前へのダウングレードはサポートされていません。さらに、TiDB 2.1 では並列 DDL が有効になっているため、バージョン 2.0.1 より前の TiDB を使用しているクラスターは、ローリングアップデートを使用して 2.1 にアップグレードできません。TiDB 2.0.6 以前から TiDB 2.1 にアップグレードする場合、進行中の DDL 操作によってアップグレードプロセスが遅くなる可能性があります。 --- # TiDB 2.1 GA リリースノート {#tidb-2-1-ga-release-notes} @@ -9,7 +9,7 @@ summary: TiDB 2.1 GA は 2018年 11月 30日にリリースされ、安定性、 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - 実行パフォーマンスを向上させるために、選択範囲`Index Join`を最適化します。 diff --git a/releases/release-2.1-rc.1.md b/releases/release-2.1-rc.1.md index 124d4e44055e5..0495085bbecfd 100644 --- a/releases/release-2.1-rc.1.md +++ b/releases/release-2.1-rc.1.md @@ -5,11 +5,11 @@ summary: TiDB 2.1 RC1は2018年8月24日にリリースされ、安定性、SQL # TiDB 2.1 RC1 リリースノート {#tidb-2-1-rc1-release-notes} -2018 年 8月 24日に、TiDB 2.1 RC1 がリリースされました。TiDB 2.1 ベータ版と比較して、このリリースでは安定性、SQL オプティマイザー、統計情報、実行エンジンが大幅に改善されています。 +2018 年 8月 24日に、TiDB 2.1 RC1 がリリースされました。TiDB 2.1 ベータ版と比較して、このリリースでは安定性、SQL オプティマイザ、統計情報、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - 相関サブクエリの相関を解除した後に間違った結果が返される場合がある問題を修正[＃6972](https://github.com/pingcap/tidb/pull/6972) - `Explain` の出力結果を最適化する [＃7041](https://github.com/pingcap/tidb/pull/7041) [＃7011](https://github.com/pingcap/tidb/pull/7011) - `IndexJoin` の外側のテーブルの選択戦略を最適化する [＃7019](https://github.com/pingcap/tidb/pull/7019) diff --git a/releases/release-2.1-rc.2.md b/releases/release-2.1-rc.2.md index 2b8584af1c6c8..41ee268845c88 100644 --- a/releases/release-2.1-rc.2.md +++ b/releases/release-2.1-rc.2.md @@ -5,11 +5,11 @@ summary: TiDB 2.1 RC2は2018年9月14日にリリースされ、安定性、SQL # TiDB 2.1 RC2 リリースノート {#tidb-2-1-rc2-release-notes} -2018年9月14日にTiDB 2.1 RC2がリリースされました。TiDB 2.1 RC1と比較して、このリリースでは安定性、SQLオプティマイザー、統計情報、実行エンジンが大幅に改善されています。 +2018年9月14日にTiDB 2.1 RC2がリリースされました。TiDB 2.1 RC1と比較して、このリリースでは安定性、SQLオプティマイザ、統計情報、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - 次世代プランナーの提案 [＃7543](https://github.com/pingcap/tidb/pull/7543) - 定数伝播の最適化ルールを改善する[＃7276](https://github.com/pingcap/tidb/pull/7276) - `Range`の計算ロジックを強化して、複数の`IN`または`EQUAL`条件を同時に処理できるようにします[＃7577](https://github.com/pingcap/tidb/pull/7577) diff --git a/releases/release-2.1-rc.3.md b/releases/release-2.1-rc.3.md index dd6a4f7343896..095b069933f4e 100644 --- a/releases/release-2.1-rc.3.md +++ b/releases/release-2.1-rc.3.md @@ -5,11 +5,11 @@ summary: TiDB 2.1 RC3は2018年9月29日にリリースされ、安定性、互 # TiDB 2.1 RC3 リリースノート {#tidb-2-1-rc3-release-notes} -2018年9月29日にTiDB 2.1 RC3がリリースされました。このリリースでは、TiDB 2.1 RC2と比較して、安定性、互換性、SQLオプティマイザー、実行エンジンが大幅に改善されています。 +2018年9月29日にTiDB 2.1 RC3がリリースされました。このリリースでは、TiDB 2.1 RC2と比較して、安定性、互換性、SQLオプティマイザ、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - 文に埋め込み`LEFT OUTER JOIN` が含まれている場合の誤った結果の問題を修正しました [＃7689](https://github.com/pingcap/tidb/pull/7689) - `JOIN`文の述語プッシュダウンの最適化ルールを強化する [＃7645](https://github.com/pingcap/tidb/pull/7645) - `UnionScan`演算子述語プッシュダウンの最適化ルールを修正 [＃7695](https://github.com/pingcap/tidb/pull/7695) diff --git a/releases/release-2.1-rc.4.md b/releases/release-2.1-rc.4.md index 60f3fca0b62fe..570335487c55c 100644 --- a/releases/release-2.1-rc.4.md +++ b/releases/release-2.1-rc.4.md @@ -5,11 +5,11 @@ summary: TiDB 2.1 RC4は2018年10月23日にリリースされ、安定性、SQL # TiDB 2.1 RC4 リリースノート {#tidb-2-1-rc4-release-notes} -2018年10月23日にTiDB 2.1 RC4がリリースされました。TiDB 2.1 RC3と比較して、このリリースでは安定性、SQLオプティマイザー、統計情報、実行エンジンが大幅に改善されています。 +2018年10月23日にTiDB 2.1 RC4がリリースされました。TiDB 2.1 RC3と比較して、このリリースでは安定性、SQLオプティマイザ、統計情報、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - `UnionAll`の列プルーニングが場合によっては正しくない問題を修正[＃7941](https://github.com/pingcap/tidb/pull/7941) - `UnionAll`演算子の結果が場合によっては正しくない問題を修正[＃8007](https://github.com/pingcap/tidb/pull/8007) - SQL実行エンジン diff --git a/releases/release-2.1-rc.5.md b/releases/release-2.1-rc.5.md index eb1bdd6d16179..95bc549222db8 100644 --- a/releases/release-2.1-rc.5.md +++ b/releases/release-2.1-rc.5.md @@ -1,17 +1,17 @@ --- title: TiDB 2.1 RC5 Release Notes -summary: TiDB 2.1 RC5は2018年11月12日にリリースされ、安定性、SQLオプティマイザー、統計、実行エンジンが改善されました。修正には、IndexReader、IndexScan Prepared Statement、Union Statement、JSONデータ変換に関する問題が含まれます。サーバーの改善には、ログの可読性、テーブルデータの取得、環境変数の追加が含まれます。PDでは、リージョンキーの読み取り、regions/check` API、PD再起動結合、イベント損失に関する問題が修正されました。TiKVでは、エラーメッセージの改善、panicマークファイルの追加、grpcioのダウングレード、`kv_scan`インターフェースへの上限設定が追加されました。 +summary: TiDB 2.1 RC5は2018年11月12日にリリースされ、安定性、SQLオプティマイザ、統計、実行エンジンが改善されました。修正には、IndexReader、IndexScan Prepared Statement、Union Statement、JSONデータ変換に関する問題が含まれます。サーバーの改善には、ログの可読性、テーブルデータの取得、環境変数の追加が含まれます。PDでは、リージョンキーの読み取り、regions/check` API、PD再起動結合、イベント損失に関する問題が修正されました。TiKVでは、エラーメッセージの改善、panicマークファイルの追加、grpcioのダウングレード、`kv_scan`インターフェースへの上限設定が追加されました。 --- # TiDB 2.1 RC5 リリースノート {#tidb-2-1-rc5-release-notes} -2018年11月12日にTiDB 2.1 RC5がリリースされました。TiDB 2.1 RC4と比較して、このリリースでは安定性、SQLオプティマイザー、統計情報、実行エンジンが大幅に改善されています。 +2018年11月12日にTiDB 2.1 RC5がリリースされました。TiDB 2.1 RC4と比較して、このリリースでは安定性、SQLオプティマイザ、統計情報、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - `IndexReader`が場合によっては間違ったハンドルを読み取る問題を修正[＃8132](https://github.com/pingcap/tidb/pull/8132) - `IndexScan Prepared`文で`Plan Cache` を使用しているときに発生する問題を修正 [＃8055](https://github.com/pingcap/tidb/pull/8055) - `Union`文の結果が不安定になる問題を修正[＃8165](https://github.com/pingcap/tidb/pull/8165) diff --git a/releases/release-2.1.1.md b/releases/release-2.1.1.md index 2af9150a95b2a..b8e3b1ea5cdb4 100644 --- a/releases/release-2.1.1.md +++ b/releases/release-2.1.1.md @@ -1,15 +1,15 @@ --- title: TiDB 2.1.1 Release Notes -summary: TiDB 2.1.1は2018年12月12日にリリースされ、安定性、SQLオプティマイザー、統計情報、実行エンジンが改善されました。修正には、負の日付の丸め誤差、解凍関数のデータ長チェック、トランザクションの再試行が含まれます。テーブルのデフォルトの文字セットと照合順序はutf8mb4に変更されました。PDとTiKVにも様々な修正と最適化が施されました。Lightningツールは分析メカニズムを最適化し、チェックポイント情報をローカルに保存するサポートを追加しました。TiDB Binlog、主キー列のみを持つテーブルのpbファイル出力のバグが修正されました。 +summary: TiDB 2.1.1は2018年12月12日にリリースされ、安定性、SQLオプティマイザ、統計情報、実行エンジンが改善されました。修正には、負の日付の丸め誤差、解凍関数のデータ長チェック、トランザクションの再試行が含まれます。テーブルのデフォルトの文字セットと照合順序はutf8mb4に変更されました。PDとTiKVにも様々な修正と最適化が施されました。Lightningツールは分析メカニズムを最適化し、チェックポイント情報をローカルに保存するサポートを追加しました。TiDB Binlog、主キー列のみを持つテーブルのpbファイル出力のバグが修正されました。 --- # TiDB 2.1.1 リリースノート {#tidb-2-1-1-release-notes} -2018年12月12日にTiDB 2.1.1がリリースされました。TiDB 2.1.0と比較して、このリリースでは安定性、SQLオプティマイザー、統計情報、実行エンジンが大幅に改善されています。 +2018年12月12日にTiDB 2.1.1がリリースされました。TiDB 2.1.0と比較して、このリリースでは安定性、SQLオプティマイザ、統計情報、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQL オプティマイザー/エグゼキューター +- SQL オプティマイザ/エグゼキューター - 負の日付の丸め誤差を修正 [＃8574](https://github.com/pingcap/tidb/pull/8574) - `uncompress`関数がデータ長チェックしない問題を修正 [＃8606](https://github.com/pingcap/tidb/pull/8606) - `execute`コマンドが実行された後に`prepare`のバインド引数をリセットする[＃8652](https://github.com/pingcap/tidb/pull/8652) diff --git a/releases/release-2.1.16.md b/releases/release-2.1.16.md index 780665da3ef49..807ccca58aa86 100644 --- a/releases/release-2.1.16.md +++ b/releases/release-2.1.16.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1.16 Release Notes -summary: TiDB 2.1.16は2019年8月15日にリリースされました。SQLオプティマイザー、SQL実行エンジン、サーバー、DDL、TiKV、TiDB Binlog、 TiDB Lightning 、TiDB Ansibleに関する様々な修正と改善が含まれています。主な変更点としては、SHOWステートメント内のサブクエリのサポート、DATE_ADD関数の問題の修正、TiDB BinlogのDrainerへの設定項目の追加などが挙げられます。 +summary: TiDB 2.1.16は2019年8月15日にリリースされました。SQLオプティマイザ、SQL実行エンジン、サーバー、DDL、TiKV、TiDB Binlog、 TiDB Lightning 、TiDB Ansibleに関する様々な修正と改善が含まれています。主な変更点としては、SHOWステートメント内のサブクエリのサポート、DATE_ADD関数の問題の修正、TiDB BinlogのDrainerへの設定項目の追加などが挙げられます。 --- # TiDB 2.1.16 リリースノート {#tidb-2-1-16-release-notes} @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 2.1.16 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - 時間列等号条件で行数が不正確に推定される問題を修正しました [＃11526](https://github.com/pingcap/tidb/pull/11526) - `TIDB_INLJ`ヒントが有効にならない、または指定されたテーブルに有効にならない問題を修正 [＃11361](https://github.com/pingcap/tidb/pull/11361) - クエリの`NOT EXISTS`の実装をOUTER JOINからANTI JOINに変更して、より最適化された実行計画見つけます [＃11291](https://github.com/pingcap/tidb/pull/11291) diff --git a/releases/release-2.1.17.md b/releases/release-2.1.17.md index 26fd10e0d9b1a..711995758ea80 100644 --- a/releases/release-2.1.17.md +++ b/releases/release-2.1.17.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1.17 Release Notes -summary: "TiDB 2.1.17 リリースノート: 新機能には、SHOW TABLE REGIONS` の `WHERE` 句、TiKV および PD の `config-check` 機能、pd-ctl の `remove-tombstone` コマンド、 Reparoの `worker-count` および `txn-batch` 構成項目が含まれます。PD のスケジュール プロセスと TiKV の起動プロセスが改善されました。TiDB スロークエリログと構成ファイルの動作が変更されました。SQL オプティマイザー、SQL 実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、および TiDB Ansible の修正と最適化が行われました。" +summary: "TiDB 2.1.17 リリースノート: 新機能には、SHOW TABLE REGIONS` の `WHERE` 句、TiKV および PD の `config-check` 機能、pd-ctl の `remove-tombstone` コマンド、 Reparoの `worker-count` および `txn-batch` 構成項目が含まれます。PD のスケジュール プロセスと TiKV の起動プロセスが改善されました。TiDB スロークエリログと構成ファイルの動作が変更されました。SQL オプティマイザ、SQL 実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、および TiDB Ansible の修正と最適化が行われました。" --- # TiDB 2.1.17 リリースノート {#tidb-2-1-17-release-notes} @@ -28,7 +28,7 @@ TiDB Ansible バージョン: 2.1.17 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - `EvalSubquery`ビルド`Executor` 中にエラーが発生したときにエラーメッセージが正しく返されない問題を修正 [＃11811](https://github.com/pingcap/tidb/pull/11811) - インデックスルックアップ結合において、外部テーブルの行数が単一バッチの行数より多い場合にクエリ結果が正しくない可能性がある問題を修正しました。インデックスルックアップ結合の機能範囲を拡張しました。`UnionScan`は `IndexJoin` のサブノードとして使用できます。 [＃11843](https://github.com/pingcap/tidb/pull/11843) - 統計フィードバック処理中に無効なキーが発生する可能性がある状況に備えて、 `SHOW STAT_BUCKETS`構文に無効なキー（ `invalid encoded key flag 252`など）の表示を追加します[＃12098](https://github.com/pingcap/tidb/pull/12098) diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index b527d037d1fe8..d693938b211d7 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1.18 Release Notes -summary: TiDB 2.1.18は2019年11月4日にリリースされました。このリリースには、SQLオプティマイザー、SQLエンジン、サーバー、DDL、モニター、ツールに関する様々な修正と最適化が含まれています。注目すべき改善点としては、ORDER BY、GROUP BY、LIMIT OFFSETにおけるパラメータの使用のサポート、インデックス追加操作の進行状況を監視するための新しいメトリクスの追加などが挙げられます。TiDB Ansibleバージョン2.1.18には、TiDB Binlogの更新と新しい監視項目も含まれています。 +summary: TiDB 2.1.18は2019年11月4日にリリースされました。このリリースには、SQLオプティマイザ、SQLエンジン、サーバー、DDL、モニター、ツールに関する様々な修正と最適化が含まれています。注目すべき改善点としては、ORDER BY、GROUP BY、LIMIT OFFSETにおけるパラメータの使用のサポート、インデックス追加操作の進行状況を監視するための新しいメトリクスの追加などが挙げられます。TiDB Ansibleバージョン2.1.18には、TiDB Binlogの更新と新しい監視項目も含まれています。 --- # TiDB 2.1.18 リリースノート {#tidb-2-1-18-release-notes} @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 2.1.18 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - フィードバックで分割すると無効なクエリ範囲が表示される可能性がある問題を修正しました [＃12172](https://github.com/pingcap/tidb/pull/12172) - PointGetプランで権限チェックが正しく行われない問題を修正 [＃12341](https://github.com/pingcap/tidb/pull/12341) - Limit演算子を`IndexLookUpReader`実行ロジックにプッシュすることで、 `select ... limit ... offset …`文の実行パフォーマンスを最適化します。 [＃12380](https://github.com/pingcap/tidb/pull/12380) diff --git a/releases/release-2.1.19.md b/releases/release-2.1.19.md index ba9a6909f379f..7fda046d9a71c 100644 --- a/releases/release-2.1.19.md +++ b/releases/release-2.1.19.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1.19 Release Notes -summary: TiDB 2.1.19は2019年12月27日にリリースされました。SQLオプティマイザー、SQL実行エンジン、サーバー、DDL、TiKV、PD、TiDB Ansibleに関する様々な修正と最適化が含まれています。主な修正としては、不正なクエリ結果の解決、メモリオーバーヘッドの削減、タイムゾーン、データ重複、panic発生に関連する問題の修正などが挙げられます。また、TiDB BinlogとTiDB Ansibleのアップグレードと最適化も含まれています。 +summary: TiDB 2.1.19は2019年12月27日にリリースされました。SQLオプティマイザ、SQL実行エンジン、サーバー、DDL、TiKV、PD、TiDB Ansibleに関する様々な修正と最適化が含まれています。主な修正としては、不正なクエリ結果の解決、メモリオーバーヘッドの削減、タイムゾーン、データ重複、panic発生に関連する問題の修正などが挙げられます。また、TiDB BinlogとTiDB Ansibleのアップグレードと最適化も含まれています。 --- # TiDB 2.1.19 リリースノート {#tidb-2-1-19-release-notes} @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 2.1.19 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - `select max(_tidb_rowid) from t`のシナリオを最適化して、テーブル全体のスキャンを回避する[＃13294](https://github.com/pingcap/tidb/pull/13294) - クエリ内のユーザー変数に割り当てられた誤った値と述語のプッシュダウンによって発生する誤った結果を修正しました[＃13230](https://github.com/pingcap/tidb/pull/13230) - 統計情報の更新時にデータ競合が発生し、統計情報が正確でない問題を修正しました[＃13690](https://github.com/pingcap/tidb/pull/13690) diff --git a/releases/release-2.1.3.md b/releases/release-2.1.3.md index 6d1a69fdba10d..3d21affaa690e 100644 --- a/releases/release-2.1.3.md +++ b/releases/release-2.1.3.md @@ -1,15 +1,15 @@ --- title: TiDB 2.1.3 Release Notes -summary: TiDB 2.1.3 および TiDB Ansible 2.1.3 がリリースされ、システムの安定性、SQL オプティマイザー、統計、実行エンジンが改善されました。修正内容には、 プリペアドプランキャッシュ、Range コンピューティング、CAST(str AS TIME(N))`、Generated カラム、統計ヒストグラム、`Sort Merge Join` などの問題が含まれています。その他の改善点としては、`_tidb_rowid` 構築クエリにおける Range のサポート、`ALLOW_INVALID_DATES` SQL モードなどが含まれます。PD および TiKV にも修正と改善が加えられています。TiDB Binlog、 Pumpクライアントログの問題と、NULL 値を含む一意のキーによって発生するデータの不整合が修正されています。 +summary: TiDB 2.1.3 および TiDB Ansible 2.1.3 がリリースされ、システムの安定性、SQL オプティマイザ、統計、実行エンジンが改善されました。修正内容には、 プリペアドプランキャッシュ、Range コンピューティング、CAST(str AS TIME(N))`、Generated カラム、統計ヒストグラム、`Sort Merge Join` などの問題が含まれています。その他の改善点としては、`_tidb_rowid` 構築クエリにおける Range のサポート、`ALLOW_INVALID_DATES` SQL モードなどが含まれます。PD および TiKV にも修正と改善が加えられています。TiDB Binlog、 Pumpクライアントログの問題と、NULL 値を含む一意のキーによって発生するデータの不整合が修正されています。 --- # TiDB 2.1.3 リリースノート {#tidb-2-1-3-release-notes} -2019年1月28日にTiDB 2.1.3がリリースされました。対応するTiDB Ansible 2.1.3もリリースされました。TiDB 2.1.2と比較して、このリリースではシステムの安定性、SQLオプティマイザー、統計情報、実行エンジンが大幅に改善されています。 +2019年1月28日にTiDB 2.1.3がリリースされました。対応するTiDB Ansible 2.1.3もリリースされました。TiDB 2.1.2と比較して、このリリースではシステムの安定性、SQLオプティマイザ、統計情報、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQL オプティマイザー/エグゼキューター +- SQL オプティマイザ/エグゼキューター - 一部のケースでプリペアドプランキャッシュのpanic問題を修正[＃8826](https://github.com/pingcap/tidb/pull/8826) - インデックスがプレフィックスインデックスの場合に範囲計算が間違っている問題を修正しました [＃8851](https://github.com/pingcap/tidb/pull/8851) - `SQL_MODE`厳密でない場合に文字列が無効な`TIME`形式の場合、 `CAST(str AS TIME(N))` nullを返すようにする[＃8966](https://github.com/pingcap/tidb/pull/8966) diff --git a/releases/release-2.1.4.md b/releases/release-2.1.4.md index ac1fc7a66a933..ecdff568ee4aa 100644 --- a/releases/release-2.1.4.md +++ b/releases/release-2.1.4.md @@ -5,11 +5,11 @@ summary: TiDB 2.1.4およびTiDB Ansible 2.1.4は、2019年2月15日にリリー # TiDB 2.1.4 リリースノート {#tidb-2-1-4-release-notes} -2019年2月15日にTiDB 2.1.4がリリースされました。対応するTiDB Ansible 2.1.4もリリースされました。このリリースでは、TiDB 2.1.3と比較して、安定性、SQLオプティマイザー、統計、実行エンジンが大幅に改善されています。 +2019年2月15日にTiDB 2.1.4がリリースされました。対応するTiDB Ansible 2.1.4もリリースされました。このリリースでは、TiDB 2.1.3と比較して、安定性、SQLオプティマイザ、統計、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQL オプティマイザー/エグゼキューター +- SQL オプティマイザ/エグゼキューター - `VALUES`関数が FLOAT 型を正しく処理しない問題を修正[＃9223](https://github.com/pingcap/tidb/pull/9223) - 一部のケースで Float を String にキャストすると結果が間違ってしまう問題を修正[＃9227](https://github.com/pingcap/tidb/pull/9227) - `FORMAT`関数が一部のケースで誤った結果を出す問題を修正[＃9235](https://github.com/pingcap/tidb/pull/9235) diff --git a/releases/release-2.1.5.md b/releases/release-2.1.5.md index 52f1e728a3333..4a351b81b81b1 100644 --- a/releases/release-2.1.5.md +++ b/releases/release-2.1.5.md @@ -1,15 +1,15 @@ --- title: TiDB 2.1.5 Release Notes -summary: TiDB 2.1.5とTiDB Ansible 2.1.5は、2019年2月28日にリリースされました。このリリースでは、安定性、SQLオプティマイザー、統計、実行エンジンが改善されています。修正には、ソート、データオーバーフロー、SQLクエリ結果に関する問題が含まれます。新機能には、システム変数、HTTP API、詳細なエラーメッセージが含まれます。PDにはTombstoneストアを除外するオプションが追加され、TiKVではリージョンマージによるデータインポート、エラー、panicに関する問題が修正されています。LightningやTiDB Binlogなどのツールもアップデートされています。 +summary: TiDB 2.1.5とTiDB Ansible 2.1.5は、2019年2月28日にリリースされました。このリリースでは、安定性、SQLオプティマイザ、統計、実行エンジンが改善されています。修正には、ソート、データオーバーフロー、SQLクエリ結果に関する問題が含まれます。新機能には、システム変数、HTTP API、詳細なエラーメッセージが含まれます。PDにはTombstoneストアを除外するオプションが追加され、TiKVではリージョンマージによるデータインポート、エラー、panicに関する問題が修正されています。LightningやTiDB Binlogなどのツールもアップデートされています。 --- # TiDB 2.1.5 リリースノート {#tidb-2-1-5-release-notes} -2019年2月28日にTiDB 2.1.5がリリースされました。対応するTiDB Ansible 2.1.5もリリースされました。このリリースでは、TiDB 2.1.4と比較して、安定性、SQLオプティマイザー、統計、実行エンジンが大幅に改善されています。 +2019年2月28日にTiDB 2.1.5がリリースされました。対応するTiDB Ansible 2.1.5もリリースされました。このリリースでは、TiDB 2.1.4と比較して、安定性、SQLオプティマイザ、統計、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQL オプティマイザー/エグゼキューター +- SQL オプティマイザ/エグゼキューター - 列の文字セット情報がテーブルの文字セット情報と同じ場合、列の文字セット情報を出力しないように`SHOW CREATE TABLE` 、 `SHOW CREATE TABLE`とMySQL の互換性を向上させます。 [＃9306](https://github.com/pingcap/tidb/pull/9306) - `Sort` の計算ロジックを簡素化するために、計算のために`Sort`から`ScalarFunc`を`Projection`演算子に抽出することにより、場合によっては`Sort`演算子のpanicまたは誤った結果を修正しました。 [＃9319](https://github.com/pingcap/tidb/pull/9319) - `Sort`演算子の定数値を持つソートフィールドを削除します[＃9440](https://github.com/pingcap/tidb/pull/9440) [＃9335](https://github.com/pingcap/tidb/pull/9335) diff --git a/releases/release-2.1.6.md b/releases/release-2.1.6.md index d8e9100cfb27e..16da078edefff 100644 --- a/releases/release-2.1.6.md +++ b/releases/release-2.1.6.md @@ -1,15 +1,15 @@ --- title: TiDB 2.1.6 Release Notes -summary: TiDB 2.1.6およびTiDB Ansible 2.1.6は、2019年3月15日にリリースされました。このリリースでは、安定性、SQLオプティマイザー、統計、実行エンジンが改善されています。SQLオプティマイザー/エグゼキューター、サーバー、DDL、TiKV、ツールの修正と機能強化が行われました。主な変更点としては、log_bin変数のサポート、トランザクションのサニティチェック、スキーマ名に英数字以外の文字が含まれていることによるインポートエラーの修正などが挙げられます。 +summary: TiDB 2.1.6およびTiDB Ansible 2.1.6は、2019年3月15日にリリースされました。このリリースでは、安定性、SQLオプティマイザ、統計、実行エンジンが改善されています。SQLオプティマイザ/エグゼキューター、サーバー、DDL、TiKV、ツールの修正と機能強化が行われました。主な変更点としては、log_bin変数のサポート、トランザクションのサニティチェック、スキーマ名に英数字以外の文字が含まれていることによるインポートエラーの修正などが挙げられます。 --- # TiDB 2.1.6 リリースノート {#tidb-2-1-6-release-notes} -2019年3月15日にTiDB 2.1.6がリリースされました。対応するTiDB Ansible 2.1.6もリリースされました。このリリースでは、TiDB 2.1.5と比較して、安定性、SQLオプティマイザー、統計、実行エンジンが大幅に改善されています。 +2019年3月15日にTiDB 2.1.6がリリースされました。対応するTiDB Ansible 2.1.6もリリースされました。このリリースでは、TiDB 2.1.5と比較して、安定性、SQLオプティマイザ、統計、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQL オプティマイザー/エグゼキューター +- SQL オプティマイザ/エグゼキューター - `TIDB_INLJ` のヒントで両方のテーブルが指定されている場合、コストに基づいて外側のテーブルを選択するようにプランナーを最適化します。 [＃9615](https://github.com/pingcap/tidb/pull/9615) - `IndexScan`正しく選択されない場合がある問題を修正[＃9587](https://github.com/pingcap/tidb/pull/9587) - サブクエリの`agg`関数のチェックにおけるMySQLとの非互換性を修正 [＃9551](https://github.com/pingcap/tidb/pull/9551) diff --git a/releases/release-3.0-beta.md b/releases/release-3.0-beta.md index 74275769fe7c8..43e76f4db3a01 100644 --- a/releases/release-3.0-beta.md +++ b/releases/release-3.0-beta.md @@ -1,11 +1,11 @@ --- title: TiDB 3.0 Beta Release Notes -summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安定性、SQLオプティマイザー、統計、実行エンジンに重点を置いています。新機能には、ビュー、ウィンドウ関数、範囲分割、ハッシュ分割のサポートが含まれます。SQLオプティマイザーは、トランザクションにおけるインデックス結合のサポート、定数伝播の最適化、DO文におけるサブクエリのサポートなど、さまざまな最適化によって強化されました。SQLエグゼキューターも最適化され、パフォーマンスが向上しました。権限管理、サーバー、互換性、DDLがすべて改善されました。TiDB Lightningは単一テーブルのバッチインポートをサポートするようになり、PDとTiKVにもさまざまな機能強化と新機能が追加されました。 +summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安定性、SQLオプティマイザ、統計、実行エンジンに重点を置いています。新機能には、ビュー、ウィンドウ関数、範囲分割、ハッシュ分割のサポートが含まれます。SQLオプティマイザは、トランザクションにおけるインデックス結合のサポート、定数伝播の最適化、DO文におけるサブクエリのサポートなど、さまざまな最適化によって強化されました。SQLエグゼキューターも最適化され、パフォーマンスが向上しました。権限管理、サーバー、互換性、DDLがすべて改善されました。TiDB Lightningは単一テーブルのバッチインポートをサポートするようになり、PDとTiKVにもさまざまな機能強化と新機能が追加されました。 --- # TiDB 3.0 ベータ版リリースノート {#tidb-3-0-beta-release-notes} -2019年1月19日、TiDB 3.0 Betaがリリースされました。対応するTiDB Ansible 3.0 Betaもリリースされました。TiDB 3.0 BetaはTiDB 2.1をベースに構築されており、安定性、SQLオプティマイザー、統計、実行エンジンに重点が置かれています。 +2019年1月19日、TiDB 3.0 Betaがリリースされました。対応するTiDB Ansible 3.0 Betaもリリースされました。TiDB 3.0 BetaはTiDB 2.1をベースに構築されており、安定性、SQLオプティマイザ、統計、実行エンジンに重点が置かれています。 ## TiDB {#tidb} @@ -14,10 +14,10 @@ summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安 - ウィンドウ関数のサポート - 範囲分割のサポート - ハッシュパーティショニングをサポート -- SQLオプティマイザー +- SQLオプティマイザ - `AggregationElimination` の最適化ルールを再サポート [＃7676](https://github.com/pingcap/tidb/pull/7676) - `NOT EXISTS`サブクエリを最適化し、Anti Semi Join に変換する [＃7842](https://github.com/pingcap/tidb/pull/7842) - - 新しいCascadesオプティマイザーをサポートするために、変数`tidb_enable_cascades_planner`追加します。現在、Cascadesオプティマイザーはまだ完全に実装されておらず、デフォルトではオフになっています[＃7879](https://github.com/pingcap/tidb/pull/7879) + - 新しいCascadesオプティマイザをサポートするために、変数`tidb_enable_cascades_planner`追加します。現在、Cascadesオプティマイザはまだ完全に実装されておらず、デフォルトではオフになっています[＃7879](https://github.com/pingcap/tidb/pull/7879) - トランザクションのインデックス結合の使用をサポート [＃7877](https://github.com/pingcap/tidb/pull/7877) - 外部結合の定数伝播を最適化し、結合結果の外部テーブルに関連するフィルタリング条件を外部結合を介して外部テーブルにプッシュダウンできるようにすることで、外部結合の無駄な計算を減らし、実行パフォーマンスを向上させます[＃7794](https://github.com/pingcap/tidb/pull/7794) - 投影除去の最適化ルールを集計除去の後の位置に調整し、冗長な`Project`演算子回避する [＃7909](https://github.com/pingcap/tidb/pull/7909) diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index bc9a493365437..2e608cf44eb6c 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0 GA Release Notes -summary: TiDB 3.0 GAは2019年6月28日にリリースされ、安定性、使いやすさ、パフォーマンスが向上しました。新機能には、ウィンドウ関数、ビュー、パーティションテーブル、プラグインフレームワークなどがあります。SQLオプティマイザーはパフォーマンス向上のために最適化され、DDLは誤って削除されたテーブルの高速リカバリをサポートするようになりました。TiKVは、分散GC、マルチスレッドRaftstore、 Raftメッセージのバッチ送受信をサポートするようになりました。TiDB LightningやTiDB Binlogなどのツールも、新機能とパフォーマンス向上によって強化されました。TiDB Ansibleは、 TiDB Lightningの導入と運用をサポートし、監視コンポーネントを最適化するためにアップグレードされました。 +summary: TiDB 3.0 GAは2019年6月28日にリリースされ、安定性、使いやすさ、パフォーマンスが向上しました。新機能には、ウィンドウ関数、ビュー、パーティションテーブル、プラグインフレームワークなどがあります。SQLオプティマイザはパフォーマンス向上のために最適化され、DDLは誤って削除されたテーブルの高速リカバリをサポートするようになりました。TiKVは、分散GC、マルチスレッドRaftstore、 Raftメッセージのバッチ送受信をサポートするようになりました。TiDB LightningやTiDB Binlogなどのツールも、新機能とパフォーマンス向上によって強化されました。TiDB Ansibleは、 TiDB Lightningの導入と運用をサポートし、監視コンポーネントを最適化するためにアップグレードされました。 --- # TiDB 3.0 GA リリースノート {#tidb-3-0-ga-release-notes} @@ -30,7 +30,7 @@ TiDB Ansible バージョン: 3.0.0 - ハッシュパーティションをサポート - IP ホワイトリスト (**Enterprise**) や監査ログ (**Enterprise**) などのプラグインをサポートするプラグインフレームワークを追加します。 - クエリの安定性を確保するために SQL 実行計画 バインディングを作成する SQL プラン管理機能をサポートします (**Experimental**) -- SQLオプティマイザー +- SQLオプティマイザ - `NOT EXISTS`サブクエリを最適化し、 `Anti Semi Join`に変換してパフォーマンスを向上させます - `Outer Join`の定数伝播を最適化し、 `Outer Join`除去の最適化ルールを追加して、効果のない計算を減らし、パフォーマンスを向上させます。 - パフォーマンスを向上させるために、集計後に`Inner Join`を実行するように`IN`サブクエリを最適化します。 diff --git a/releases/release-3.0.0-beta.1.md b/releases/release-3.0.0-beta.1.md index d2110ba33a271..c09a0aac28f2e 100644 --- a/releases/release-3.0.0-beta.1.md +++ b/releases/release-3.0.0-beta.1.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.0 Beta.1 Release Notes -summary: TiDB 3.0.0 Beta.1は2019年3月26日にリリースされ、安定性、ユーザビリティ、機能、SQLオプティマイザー、統計、実行エンジンが改善されました。このリリースには、さまざまなSQL関数のサポート、権限管理、サーバーの機能強化、DDLの改善、PDおよびTiKVの最適化が含まれています。TiDB Binlog、Lightning、データレプリケーション比較ツールなどのツールも、新機能と改善が追加されてアップデートされました。 +summary: TiDB 3.0.0 Beta.1は2019年3月26日にリリースされ、安定性、ユーザビリティ、機能、SQLオプティマイザ、統計、実行エンジンが改善されました。このリリースには、さまざまなSQL関数のサポート、権限管理、サーバーの機能強化、DDLの改善、PDおよびTiKVの最適化が含まれています。TiDB Binlog、Lightning、データレプリケーション比較ツールなどのツールも、新機能と改善が追加されてアップデートされました。 --- # TiDB 3.0.0 ベータ.1 リリースノート {#tidb-3-0-0-beta-1-release-notes} @@ -13,11 +13,11 @@ TiDB Ansible バージョン: 3.0.0-beta.1 ## 概要 {#overview} -2019年3月26日にTiDB 3.0.0 Beta.1がリリースされました。対応するTiDB Ansibleバージョンは3.0.0 Beta.1です。TiDB 3.0.0 Betaと比較して、このリリースでは安定性、使いやすさ、機能、SQLオプティマイザー、統計、実行エンジンが大幅に向上しています。 +2019年3月26日にTiDB 3.0.0 Beta.1がリリースされました。対応するTiDB Ansibleバージョンは3.0.0 Beta.1です。TiDB 3.0.0 Betaと比較して、このリリースでは安定性、使いやすさ、機能、SQLオプティマイザ、統計、実行エンジンが大幅に向上しています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - `Sort Merge Join` を使用して直積を計算することをサポートします [＃9032](https://github.com/pingcap/tidb/pull/9037) - スカイラインプルーニングをサポートし、実行計画が統計情報に過度に依存しないようにするいくつかのルールを備えています[＃9337](https://github.com/pingcap/tidb/pull/9337) diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md index 83531d5eb7b65..ddeef98e79d0a 100644 --- a/releases/release-3.0.0-rc.1.md +++ b/releases/release-3.0.0-rc.1.md @@ -13,11 +13,11 @@ TiDB Ansible バージョン: 3.0.0-rc.1 ## 概要 {#overview} -2019年5月10日にTiDB 3.0.0-rc.1がリリースされました。対応するTiDB Ansibleバージョンは3.0.0-rc.1です。このリリースでは、TiDB 3.0.0-beta.1と比較して、安定性、使いやすさ、機能、SQLオプティマイザー、統計、実行エンジンが大幅に改善されています。 +2019年5月10日にTiDB 3.0.0-rc.1がリリースされました。対応するTiDB Ansibleバージョンは3.0.0-rc.1です。このリリースでは、TiDB 3.0.0-beta.1と比較して、安定性、使いやすさ、機能、SQLオプティマイザ、統計、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - 列間の順序相関を使用してコスト見積りの精度を向上させます。相関を見積りに直接使用できない場合に、インデックススキャンの優先順位を制御するヒューリスティックパラメータ`tidb_opt_correlation_exp_factor`を導入します[＃9839](https://github.com/pingcap/tidb/pull/9839) - フィルタに関連する列がある場合、複合インデックスのアクセス条件を抽出するときに、インデックスのプレフィックス列をさらに一致させます。 [＃10053](https://github.com/pingcap/tidb/pull/10053) - 結合に含まれるテーブルの数が`tidb_opt_join_reorder_threshold`未満の場合に、結合操作の実行順序を指定するには、動的計画法アルゴリズムを使用します[＃8816](https://github.com/pingcap/tidb/pull/8816) diff --git a/releases/release-3.0.0-rc.2.md b/releases/release-3.0.0-rc.2.md index 840fbd358b851..b7a29e5a09837 100644 --- a/releases/release-3.0.0-rc.2.md +++ b/releases/release-3.0.0-rc.2.md @@ -13,11 +13,11 @@ TiDB Ansible バージョン: 3.0.0-rc.2 ## 概要 {#overview} -2019年5月28日にTiDB 3.0.0-rc.2がリリースされました。対応するTiDB Ansibleバージョンは3.0.0-rc.2です。このリリースでは、TiDB 3.0.0-rc.1と比較して、安定性、使いやすさ、機能、SQLオプティマイザー、統計、実行エンジンが大幅に向上しています。 +2019年5月28日にTiDB 3.0.0-rc.2がリリースされました。対応するTiDB Ansibleバージョンは3.0.0-rc.2です。このリリースでは、TiDB 3.0.0-rc.1と比較して、安定性、使いやすさ、機能、SQLオプティマイザ、統計、実行エンジンが大幅に向上しています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - サポートインデックス より多くのシナリオに参加[＃10540](https://github.com/pingcap/tidb/pull/10540) - 履歴統計のエクスポートをサポート[＃10291](https://github.com/pingcap/tidb/pull/10291) - 単調に増加するインデックス列に対する増分`Analyze`操作をサポートする [＃10355](https://github.com/pingcap/tidb/pull/10355) diff --git a/releases/release-3.0.0-rc.3.md b/releases/release-3.0.0-rc.3.md index f90eaa1732b1d..bab6c3a7a35ca 100644 --- a/releases/release-3.0.0-rc.3.md +++ b/releases/release-3.0.0-rc.3.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.0-rc.3 Release Notes -summary: TiDB 3.0.0-rc.3は2019年6月21日にリリースされ、安定性、ユーザビリティ、機能、SQLオプティマイザー、統計、実行エンジンが改善されました。TiDB、PD、TiKV、TiDB Ansibleに修正と新機能が追加されました。主な改善点としては、統計情報の自動読み込み、テーブルとインデックス領域の手動分割、TiKVにおける悲観的トランザクションのサポートなどが挙げられます。 +summary: TiDB 3.0.0-rc.3は2019年6月21日にリリースされ、安定性、ユーザビリティ、機能、SQLオプティマイザ、統計、実行エンジンが改善されました。TiDB、PD、TiKV、TiDB Ansibleに修正と新機能が追加されました。主な改善点としては、統計情報の自動読み込み、テーブルとインデックス領域の手動分割、TiKVにおける悲観的トランザクションのサポートなどが挙げられます。 --- # TiDB 3.0.0-rc.3 リリースノート {#tidb-3-0-0-rc-3-release-notes} @@ -13,11 +13,11 @@ TiDB Ansible バージョン: 3.0.0-rc.3 ## 概要 {#overview} -2019年6月21日にTiDB 3.0.0-rc.3がリリースされました。対応するTiDB Ansibleバージョンは3.0.0-rc.3です。このリリースでは、TiDB 3.0.0-rc.2と比較して、安定性、使いやすさ、機能、SQLオプティマイザー、統計、実行エンジンが大幅に向上しています。 +2019年6月21日にTiDB 3.0.0-rc.3がリリースされました。対応するTiDB Ansibleバージョンは3.0.0-rc.3です。このリリースでは、TiDB 3.0.0-rc.2と比較して、安定性、使いやすさ、機能、SQLオプティマイザ、統計、実行エンジンが大幅に向上しています。 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - 仮想生成列統計を収集する機能を削除します [＃10629](https://github.com/pingcap/tidb/pull/10629) - ポイントクエリ中に主キー定数がオーバーフローする問題を修正[＃10699](https://github.com/pingcap/tidb/pull/10699) - `fast analyze`で初期化されていない情報を使用するとpanicが発生する問題を修正[＃10691](https://github.com/pingcap/tidb/pull/10691) diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index 236e784f5e074..d94ad645f08b0 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.2 Release Notes -summary: TiDB 3.0.2は、2019年8月7日にリリースされ、様々な修正と改善が行われました。このリリースには、SQLオプティマイザー、SQL実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、TiDB Ansibleの修正が含まれています。修正には、クエリプラン、クエリ結果、エラーメッセージ、パフォーマンス最適化に関する問題が含まれます。 +summary: TiDB 3.0.2は、2019年8月7日にリリースされ、様々な修正と改善が行われました。このリリースには、SQLオプティマイザ、SQL実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、TiDB Ansibleの修正が含まれています。修正には、クエリプラン、クエリ結果、エラーメッセージ、パフォーマンス最適化に関する問題が含まれます。 --- # TiDB 3.0.2 リリースノート {#tidb-3-0-2-release-notes} @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 3.0.2 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - クエリ内で同じテーブルが複数回出現し、論理的にクエリ結果が常に空になる場合に「スキーマ内に列が見つかりません」というメッセージが報告される問題を修正しました[＃11247](https://github.com/pingcap/tidb/pull/11247) - `TIDB_INLJ`ヒントが一部のケース（ `explain select /*+ TIDB_INLJ(t1) */ t1.b, t2.a from t t1, t t2 where t1.b = t2.a`など）で正しく機能しないことが原因でクエリプランが期待どおりに動作しない問題を修正しました[＃11362](https://github.com/pingcap/tidb/pull/11362) - クエリ結果の列名が場合によっては間違っている問題を修正しました（ `SELECT IF(1,c,c) FROM t`など） [＃11379](https://github.com/pingcap/tidb/pull/11379) @@ -23,7 +23,7 @@ TiDB Ansible バージョン: 3.0.2 - ウィンドウ関数で構文制限に違反した場合にエラーが報告されない問題を修正しました（例： `UNBOUNDED PRECEDING`フレーム定義の最後に出現できません） [＃11543](https://github.com/pingcap/tidb/pull/11543) - `ERROR 3593 (HY000): You cannot use the window function FUNCTION_NAME in this context`エラーメッセージで`FUNCTION_NAME`大文字になっているため、MySQL との非互換性が発生する問題を修正しました。 [＃11535](https://github.com/pingcap/tidb/pull/11535) - ウィンドウ関数で実装されていない`IGNORE NULLS`構文が使用されているにもかかわらずエラーが報告されない問題を修正[＃11593](https://github.com/pingcap/tidb/pull/11593) - - オプティマイザーが時間等条件正しく推定しない問題を修正 [＃11512](https://github.com/pingcap/tidb/pull/11512) + - オプティマイザが時間等条件正しく推定しない問題を修正 [＃11512](https://github.com/pingcap/tidb/pull/11512) - フィードバック情報に基づいてトップN統計を更新することをサポート[＃11507](https://github.com/pingcap/tidb/pull/11507) - SQL実行エンジン - 関数`INSERT`パラメータに`NULL`含まれている場合、戻り値が`NULL`ならない問題を修正しました。 [＃11248](https://github.com/pingcap/tidb/pull/11248) diff --git a/releases/release-3.0.3.md b/releases/release-3.0.3.md index 52b8f3352e612..163209585aa19 100644 --- a/releases/release-3.0.3.md +++ b/releases/release-3.0.3.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.3 Release Notes -summary: TiDB 3.0.3は2019年8月29日にリリースされました。SQLオプティマイザー、SQL実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、TiDB Ansibleに関する様々な修正とアップデートが含まれています。主な修正には、不正な結果、型エラー、panic発生、権限チェックエラーに関する問題が含まれます。また、PD操作の最適化、サポート対象外のGrafana Collectorコンポーネントの削除、TiKVアラートルールの更新も行われています。さらに、TiDB AnsibleはSpark V2.4.3とTiSpark V2.1.4をサポートするようになりました。 +summary: TiDB 3.0.3は2019年8月29日にリリースされました。SQLオプティマイザ、SQL実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、TiDB Ansibleに関する様々な修正とアップデートが含まれています。主な修正には、不正な結果、型エラー、panic発生、権限チェックエラーに関する問題が含まれます。また、PD操作の最適化、サポート対象外のGrafana Collectorコンポーネントの削除、TiKVアラートルールの更新も行われています。さらに、TiDB AnsibleはSpark V2.4.3とTiSpark V2.1.4をサポートするようになりました。 --- # TiDB 3.0.3 リリースノート {#tidb-3-0-3-release-notes} @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 3.0.3 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - `aggregation_eliminate`や`column_prune`などのロジック最適化ルールを無効にするには、 `opt_rule_blacklist`テーブルを追加します[＃11658](https://github.com/pingcap/tidb/pull/11658) - 結合キーがプレフィックスインデックスまたは負の値に等しい符号なしインデックス列を使用する場合に、 `Index Join`に対して誤った結果が返される可能性がある問題を修正しました[＃11759](https://github.com/pingcap/tidb/pull/11759) - `create … binding ...`の`SELECT`つの文のうち`"`または`\`解析エラーになる可能性がある問題を修正しました[＃11726](https://github.com/pingcap/tidb/pull/11726) diff --git a/releases/release-3.0.4.md b/releases/release-3.0.4.md index 1ad6c5af79419..783a622e8c23d 100644 --- a/releases/release-3.0.4.md +++ b/releases/release-3.0.4.md @@ -41,7 +41,7 @@ TiDB Ansible バージョン: 3.0.4 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - フィードバックで分割すると無効なクエリ範囲が生成される可能性がある問題を修正しました [＃12170](https://github.com/pingcap/tidb/pull/12170) - 結果に無効なキーが含まれている場合はエラーを返すのではなく、 `SHOW STATS_BUCKETS`のステートメントの返されたエラーを16進数で表示します。 [＃12094](https://github.com/pingcap/tidb/pull/12094) - クエリに`SLEEP`関数（たとえば`select 1 from (select sleep(1)) t;)` ）が含まれている場合、列プルーニングによってクエリ中に無効な`sleep(1)`発生する問題を修正しました。 [＃11953](https://github.com/pingcap/tidb/pull/11953) diff --git a/releases/release-3.0.5.md b/releases/release-3.0.5.md index 040c40e92d1c0..686492a0f1ff1 100644 --- a/releases/release-3.0.5.md +++ b/releases/release-3.0.5.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.5 Release Notes -summary: TiDB 3.0.5は、2019年10月25日にリリースされ、様々な改善とバグ修正が行われました。このリリースには、SQLオプティマイザー、SQL実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、TiDB Ansibleの機能強化が含まれています。改善点には、ウィンドウ関数の境界チェックのサポート、インデックス結合と外部結合の問題の修正、各種操作の監視メトリクスの追加などがあります。さらに、TiKVではストレージとパフォーマンスの最適化が行われ、PDではストレージ精度とHTTPリクエスト処理が改善されました。TiDB Ansibleでは、監視メトリクスのアップデートと設定ファイルの簡素化も行われました。 +summary: TiDB 3.0.5は、2019年10月25日にリリースされ、様々な改善とバグ修正が行われました。このリリースには、SQLオプティマイザ、SQL実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、TiDB Ansibleの機能強化が含まれています。改善点には、ウィンドウ関数の境界チェックのサポート、インデックス結合と外部結合の問題の修正、各種操作の監視メトリクスの追加などがあります。さらに、TiKVではストレージとパフォーマンスの最適化が行われ、PDではストレージ精度とHTTPリクエスト処理が改善されました。TiDB Ansibleでは、監視メトリクスのアップデートと設定ファイルの簡素化も行われました。 --- # TiDB 3.0.5 リリースノート {#tidb-3-0-5-release-notes} @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 3.0.5 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - ウィンドウ関数の境界チェックをサポート [＃12404](https://github.com/pingcap/tidb/pull/12404) - パーティションテーブル`IndexJoin`が誤った結果を返す問題を修正[＃12712](https://github.com/pingcap/tidb/pull/12712) - 外部結合演算子`Apply`の先頭の`ifnull`関数が誤った結果を返す問題を修正[＃12694](https://github.com/pingcap/tidb/pull/12694) diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 7d82a778d615d..cb7e917df5097 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.6 Release Notes -summary: TiDB 3.0.6は、さまざまな修正と最適化を伴い、2019年11月28日にリリースされました。このリリースには、SQLオプティマイザー、SQL実行エンジン、サーバー、DDL、TiKV、PD、TiDB Binlog、およびTiDB Lightningの改善が含まれています。修正には、ウィンドウ関数ASTの問題、STREAM AGG()`のプッシュダウン、SQLバインディングの引用符の処理などが含まれます。TiKVの改善には、正確な`lock_manager`、`innodb_lock_wait_timeout`のサポート、`tikv-ctl`を使用したGC I/O制限の動的な変更が含まれます。PDの機能強化には、クライアントログレベルの引き下げと、タイムスタンプ生成のための警告ログが含まれます。TiDB BinlogとTiDB Lightningにも修正と改善が加えられました。 +summary: TiDB 3.0.6は、さまざまな修正と最適化を伴い、2019年11月28日にリリースされました。このリリースには、SQLオプティマイザ、SQL実行エンジン、サーバー、DDL、TiKV、PD、TiDB Binlog、およびTiDB Lightningの改善が含まれています。修正には、ウィンドウ関数ASTの問題、STREAM AGG()`のプッシュダウン、SQLバインディングの引用符の処理などが含まれます。TiKVの改善には、正確な`lock_manager`、`innodb_lock_wait_timeout`のサポート、`tikv-ctl`を使用したGC I/O制限の動的な変更が含まれます。PDの機能強化には、クライアントログレベルの引き下げと、タイムスタンプ生成のための警告ログが含まれます。TiDB BinlogとTiDB Lightningにも修正と改善が加えられました。 --- # TiDB 3.0.6 リリースノート {#tidb-3-0-6-release-notes} @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 3.0.6 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - ウィンドウ関数 AST が SQL テキストを復元した後に結果が正しくない (たとえば、 `over w`が誤って`over (w)` に復元される) 問題を修正しました。 [＃12933](https://github.com/pingcap/tidb/pull/12933) - `STREAM AGG()`から`doubleRead` プッシュダウンする問題を修正 [＃12690](https://github.com/pingcap/tidb/pull/12690) - SQLバインディングで引用符が正しく処理されない問題を修正 [＃13117](https://github.com/pingcap/tidb/pull/13117) diff --git a/releases/release-3.0.8.md b/releases/release-3.0.8.md index 7c5d8a1a7da92..a32aa927cf9ac 100644 --- a/releases/release-3.0.8.md +++ b/releases/release-3.0.8.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.8 Release Notes -summary: TiDB 3.0.8は2019年12月31日にリリースされました。SQLオプティマイザー、SQL実行エンジン、DDL、サーバー、トランザクション、モニター、TiKV、PD、TiDB Ansibleに関する様々な修正と改善が含まれています。主な変更点としては、SQLバインディングプランの修正、エラーメッセージの最適化、証明書ベースの認証のサポートなどが挙げられます。tidb_txn_mode`変数のデフォルト値が`"悲観的"`に更新されました。PDではパフォーマンスの最適化とバグ修正も行われました。TiDB Ansibleでは、様々なロジックの最適化とアップグレードが行われました。 +summary: TiDB 3.0.8は2019年12月31日にリリースされました。SQLオプティマイザ、SQL実行エンジン、DDL、サーバー、トランザクション、モニター、TiKV、PD、TiDB Ansibleに関する様々な修正と改善が含まれています。主な変更点としては、SQLバインディングプランの修正、エラーメッセージの最適化、証明書ベースの認証のサポートなどが挙げられます。tidb_txn_mode`変数のデフォルト値が`"悲観的"`に更新されました。PDではパフォーマンスの最適化とバグ修正も行われました。TiDB Ansibleでは、様々なロジックの最適化とアップグレードが行われました。 --- # TiDB 3.0.8 リリースノート {#tidb-3-0-8-release-notes} @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 3.0.8 ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - タイミングの悪いキャッシュ更新によって発生した間違ったSQLバインディングプランを修正[＃13891](https://github.com/pingcap/tidb/pull/13891) - SQL文にシンボルリストが含まれている場合にSQLバインディングが無効になる可能性がある問題を修正しました [＃14004](https://github.com/pingcap/tidb/pull/14004) - SQL文が`;` で終わるためSQLバインディングを作成または削除できない問題を修正しました [＃14113](https://github.com/pingcap/tidb/pull/14113) diff --git a/releases/release-3.1.0-beta.md b/releases/release-3.1.0-beta.md index 9218ed2a36798..1469cc4374bc0 100644 --- a/releases/release-3.1.0-beta.md +++ b/releases/release-3.1.0-beta.md @@ -1,6 +1,6 @@ --- title: TiDB 3.1 Beta Release Notes -summary: TiDB 3.1ベータ版は2019年12月20日にリリースされました。SQLオプティマイザーの改良に加え、Follower Read機能もサポートされています。TiKVは、Follower Read機能に加え、分散バックアップとリストアをサポートするようになりました。PDも分散バックアップとリストアをサポートします。 +summary: TiDB 3.1ベータ版は2019年12月20日にリリースされました。SQLオプティマイザの改良に加え、Follower Read機能もサポートされています。TiKVは、Follower Read機能に加え、分散バックアップとリストアをサポートするようになりました。PDも分散バックアップとリストアをサポートします。 --- # TiDB 3.1 ベータ版リリースノート {#tidb-3-1-beta-release-notes} @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 3.1.0-beta ## TiDB {#tidb} -- SQLオプティマイザー +- SQLオプティマイザ - SQLヒントの強化[＃12192](https://github.com/pingcap/tidb/pull/12192) - 新機能 - Follower Read機能サポートする [＃12535](https://github.com/pingcap/tidb/pull/12535) diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index 027cda150042e..268efe87dbc14 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -1,6 +1,6 @@ --- title: TiDB 5.0 RC Release Notes -summary: TiDB v5.0.0-rcはTiDB v5.0の前身バージョンです。クラスター化インデックス、非同期コミット、ジッターの低減、 Raft Joint Consensusアルゴリズム、最適化された「EXPLAIN」機能、不可視インデックス、エンタープライズデータの信頼性向上などの新機能が含まれています。また、セキュリティ対策として、エラーメッセージとログファイルの感度低下もサポートしています。パフォーマンス向上には、非同期コミット、オプティマイザーの安定性、パフォーマンスジッターの低減が含まれます。また、リージョンメンバーシップ変更時のシステム可用性も向上します。さらに、AWS S3およびGoogle Cloud GCSへのバックアップとリストア、データのインポート/エクスポート、SQLパフォーマンスの問題のトラブルシューティングのための最適化された「EXPLAIN」機能もサポートしています。導入とメンテナンスの改善には、強化された「mirror」コマンドとより簡単なインストールプロセスが含まれます。 +summary: TiDB v5.0.0-rcはTiDB v5.0の前身バージョンです。クラスター化インデックス、非同期コミット、ジッターの低減、 Raft Joint Consensusアルゴリズム、最適化された「EXPLAIN」機能、不可視インデックス、エンタープライズデータの信頼性向上などの新機能が含まれています。また、セキュリティ対策として、エラーメッセージとログファイルの感度低下もサポートしています。パフォーマンス向上には、非同期コミット、オプティマイザの安定性、パフォーマンスジッターの低減が含まれます。また、リージョンメンバーシップ変更時のシステム可用性も向上します。さらに、AWS S3およびGoogle Cloud GCSへのバックアップとリストア、データのインポート/エクスポート、SQLパフォーマンスの問題のトラブルシューティングのための最適化された「EXPLAIN」機能もサポートしています。導入とメンテナンスの改善には、強化された「mirror」コマンドとより簡単なインストールプロセスが含まれます。 --- # TiDB 5.0 RC リリースノート {#tidb-5-0-rc-release-notes} @@ -15,7 +15,7 @@ v5.0 の主な新機能または改善点は次のとおりです。 - クラスター化インデックス。この機能を有効にすると、データベースのパフォーマンスが向上します。例えば、TPC-C tpmCテストでは、クラスター化インデックスを有効にしたTiDBのパフォーマンスは39%向上しました。 - 非同期コミット。この機能を有効にすると、書き込みレイテンシーが短縮されます。例えば、Sysbench olpt-insert テストでは、非同期コミットを有効にした TiDB の書き込みレイテンシーが 37.3% 短縮されます。 -- ジッターの低減。これは、オプティマイザーの安定性を向上させ、システムタスクによるI/O、ネットワーク、CPU、メモリリソースの使用を制限することで実現されます。例えば、72時間のパフォーマンステストでは、Sysbench TPSジッターの標準偏差が11.09%から3.36%に低減しました。 +- ジッターの低減。これは、オプティマイザの安定性を向上させ、システムタスクによるI/O、ネットワーク、CPU、メモリリソースの使用を制限することで実現されます。例えば、72時間のパフォーマンステストでは、Sysbench TPSジッターの標準偏差が11.09%から3.36%に低減しました。 - リージョンメンバーシップの変更中にシステムの可用性を確保するRaftジョイント コンセンサス アルゴリズム。 - 最適化された`EXPLAIN`機能と不可視インデックスにより、データベース管理者 (DBA) は SQL ステートメントをより効率的にデバッグできるようになります。 - エンタープライズデータの信頼性を保証します。TiDBからAWS S3ストレージやGoogle Cloud GCSにデータをバックアップしたり、これらのクラウドストレージプラットフォームからデータを復元したりできます。 diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 05b019cce2a41..b9777eeb26a1b 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -80,7 +80,7 @@ TiDB バージョン: 6.1.0 - 結合順序ヒント構文をサポートする - The `LEADING` hint reminds the optimizer to use the specified order as the prefix of join operations. A good prefix of join can quickly reduce the amount of data at the early phase of join and improve the query performance. - - `STRAIGHT_JOIN`ヒントは、 `FROM`句内のテーブルの順序と一致する順序でテーブルを結合するようにオプティマイザーに通知します。 + - `STRAIGHT_JOIN`ヒントは、 `FROM`句内のテーブルの順序と一致する順序でテーブルを結合するようにオプティマイザに通知します。 これにより、テーブル結合の順序を固定することができます。ヒントを適切に使用することで、SQLパフォーマンスとクラスタの安定性を効果的に向上させることができます。 diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index f17b9814db676..ce6982e1c6ecc 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -1,6 +1,6 @@ --- title: TiDB 6.1.1 Release Notes -summary: TiDB 6.1.1は2022年9月1日にリリースされました。変更点には、大文字と小文字を区別しない「SHOW DATABASES LIKE」ステートメント、「tidb_enable_outer_join_reorder」のデフォルト値の変更、オプティマイザーとメトリクスレスポンスの圧縮の改善が含まれます。バグ修正では、「INL_HASH_JOIN」のハング、UPDATE`ステートメント実行中のパニック、クエリ結果の誤りなどの問題が修正されています。その他の変更点には、異なる品質基準に対するマルチレベルサポートと、「TiDB-community-toolkit」バイナリパッケージへの追加が含まれます。 +summary: TiDB 6.1.1は2022年9月1日にリリースされました。変更点には、大文字と小文字を区別しない「SHOW DATABASES LIKE」ステートメント、「tidb_enable_outer_join_reorder」のデフォルト値の変更、オプティマイザとメトリクスレスポンスの圧縮の改善が含まれます。バグ修正では、「INL_HASH_JOIN」のハング、UPDATE`ステートメント実行中のパニック、クエリ結果の誤りなどの問題が修正されています。その他の変更点には、異なる品質基準に対するマルチレベルサポートと、「TiDB-community-toolkit」バイナリパッケージへの追加が含まれます。 --- # TiDB 6.1.1 Release Notes {#tidb-6-1-1-release-notes} diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 9e7068a7e2b60..6155218fcfb96 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -113,7 +113,7 @@ TiDBバージョン: 6.3.0-DMR TiDB v6.3.0 では、新しい結合[ヌル値認識型アンチジョイン（NAAJ）](/explain-subqueries.md#null-aware-anti-semi-join-not-in-and--all-subqueries)が導入されています。 NAAJ は、コレクション操作を処理するときに、コレクションが空であるか、 `NULL`であるかを認識できます。これにより`IN`や`= ANY`などの操作の実行効率が最適化され、SQL パフォーマンスが向上します。 -- ハッシュ結合のビルド終了を制御するオプティマイザーヒントを追加 [#35439](https://github.com/pingcap/tidb/issues/35439) @[Reminiscent](https://github.com/Reminiscent) +- ハッシュ結合のビルド終了を制御するオプティマイザヒントを追加 [#35439](https://github.com/pingcap/tidb/issues/35439) @[Reminiscent](https://github.com/Reminiscent) バージョン6.3.0では、TiDBオプティマイザに、ハッシュ結合、そのプローブ終了、および構築終了を指定するための2つのヒント、 `HASH_JOIN_BUILD()`と`HASH_JOIN_PROBE()`が導入されました。オプティマイザが最適な実行計画を選択できない場合、これらのヒントを使用してプランに介入できます。 diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 0420356b81413..35f9f3639c50c 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -99,7 +99,7 @@ TiDBバージョン: 6.4.0-DMR 詳細については、 [ユーザー向けドキュメント](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を参照してください。 -- 相関サブクエリの非相関化を実行するかどうかを制御する新しいオプティマイザーヒント`NO_DECORRELATE`を導入します [#37789](https://github.com/pingcap/tidb/issues/37789) @[time-and-fate](https://github.com/time-and-fate) +- 相関サブクエリの非相関化を実行するかどうかを制御する新しいオプティマイザヒント`NO_DECORRELATE`を導入します [#37789](https://github.com/pingcap/tidb/issues/37789) @[time-and-fate](https://github.com/time-and-fate) TiDB はデフォルトでは、相関のあるサブクエリを書き換えて相関解除を実行しようとします。これにより、通常は実行効率が向上します。しかし、シナリオによっては相関解除によって実行効率が低下する場合があります。v6.4.0 では、オプティマイザヒント`NO_DECORRELATE`が導入され、特定のクエリブロックに対して相関解除を実行しないようにオプティマイザに指示することで、シナリオによってはクエリのパフォーマンスが向上します。 diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index d1a3780c60ffb..33de36d298115 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -26,7 +26,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - TiDB グローバルメモリ制御が GA になり、 [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)を介してメモリ消費しきい値を制御できるようになりました。 - 高性能かつグローバルに単調な[`AUTO_INCREMENT`](/auto-increment.md#mysql-compatibility-mode)列属性が、MySQLと互換性のあるGAになります。 - [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)は TiCDC および PITR と互換性があり、GA になります。 -- より正確な[コストモデル バージョン 2](/cost-model.md#cost-model-version-2)一般に公開し、 `AND`で[インデックスマージ](/explain-index-merge.md)に接続された式をサポートすることで、 TiDB オプティマイザーを強化します。 +- より正確な[コストモデル バージョン 2](/cost-model.md#cost-model-version-2)一般に公開し、 `AND`で[インデックスマージ](/explain-index-merge.md)に接続された式をサポートすることで、 TiDB オプティマイザを強化します。 - `JSON_EXTRACT()`機能をTiFlashにプッシュダウンすることをサポートします。 - パスワード コンプライアンス監査要件を満たす[パスワード管理](/password-management.md)ポリシーをサポートします。 - TiDB LightningとDumplingは、圧縮されたSQLおよびCSVファイルの[インポート](/tidb-lightning/tidb-lightning-data-source.md)および[エクスポート](/dumpling-overview.md#improve-export-efficiency-through-concurrency)をサポートします。 @@ -177,11 +177,11 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では [パーティションテーブル](/partitioned-table.md)機能は v6.1.0 から GA となっていますが、TiDB は継続的にパフォーマンスを改善しています。v6.5.0 では、TiDB は計算とフィルタリングのために`ORDER BY`や`LIMIT`などのソート操作を TiKV にプッシュダウンすることをサポートします。これにより、ネットワーク I/O オーバーヘッドが削減され、パーティションテーブル使用時の SQL パフォーマンスが向上します。 -- オプティマイザーはより正確なコストモデルバージョン2（GA） を導入しました [＃35240](https://github.com/pingcap/tidb/issues/35240) @[qw4990](https://github.com/qw4990) +- オプティマイザはより正確なコストモデルバージョン2（GA） を導入しました [＃35240](https://github.com/pingcap/tidb/issues/35240) @[qw4990](https://github.com/qw4990) - TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)が実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行計画を選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 + TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)が実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザが最適な実行計画を選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 - コストモデル バージョン 2 は、TiDB オプティマイザーの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。 + コストモデル バージョン 2 は、TiDB オプティマイザの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。 詳細については[ドキュメント](/cost-model.md#cost-model-version-2)を参照してください。 diff --git a/releases/release-6.5.10.md b/releases/release-6.5.10.md index 4c3f707ec48f4..15a6c6ae322a2 100644 --- a/releases/release-6.5.10.md +++ b/releases/release-6.5.10.md @@ -56,7 +56,7 @@ TiDB バージョン: 6.5.10 - TiDB を再起動した後、主キー列統計のヒストグラムと TopN がロードされない問題を修正しました [＃37548](https://github.com/pingcap/tidb/issues/37548) @[hawkingrei](https://github.com/hawkingrei) - クエリ内の特定のフィルター条件により、プランナーモジュールが`invalid memory address or nil pointer dereference`エラー[＃53582](https://github.com/pingcap/tidb/issues/53582) [＃53580](https://github.com/pingcap/tidb/issues/53580) を報告する可能性がある問題を修正しました [＃53603](https://github.com/pingcap/tidb/issues/53603) @[YangKeao](https://github.com/YangKeao) [＃53594](https://github.com/pingcap/tidb/issues/53594) - `?`引数を含む`CONV` `EXECUTE` `PREPARE`を複数回実行すると、誤ったクエリ結果が返される可能性がある問題を修正しました[＃53505](https://github.com/pingcap/tidb/issues/53505) @[qw4990](https://github.com/qw4990) - - オプティマイザーヒント使用時に誤った警告情報が表示される問題を修正しました [＃53767](https://github.com/pingcap/tidb/issues/53767) @[hawkingrei](https://github.com/hawkingrei) + - オプティマイザヒント使用時に誤った警告情報が表示される問題を修正しました [＃53767](https://github.com/pingcap/tidb/issues/53767) @[hawkingrei](https://github.com/hawkingrei) - 情報スキーマキャッシュミスにより、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 [＃53428](https://github.com/pingcap/tidb/issues/53428) @[crazycs520](https://github.com/crazycs520) - DDL ステートメントが etcd を誤って使用し、タスクがキューに入れられる問題を修正しました。 [＃52335](https://github.com/pingcap/tidb/issues/52335) @[wjhuang2016](https://github.com/wjhuang2016) - 式インデックスの名前を変更する`RENAME INDEX`を実行したときに内部列の名前が変更されない問題を修正しました [＃51431](https://github.com/pingcap/tidb/issues/51431) @[ywqzzy](https://github.com/ywqzzy) diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index 56380da1d5a56..8df1a3966d109 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -98,7 +98,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone 詳細については、 [ドキュメント](/sql-plan-management.md#create-a-binding-according-to-a-historical-execution-plan)を参照してください。 -- いくつかのオプティマイザーヒントを追加 [#39964](https://github.com/pingcap/tidb/issues/39964) @[Reminiscent](https://github.com/Reminiscent) +- いくつかのオプティマイザヒントを追加 [#39964](https://github.com/pingcap/tidb/issues/39964) @[Reminiscent](https://github.com/Reminiscent) TiDB は v6.6.0 で`LIMIT`操作の実行計画の選択を制御するためのオプティマイザヒントをいくつか追加しました。 @@ -388,7 +388,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - `ADD INDEX`の分散データバックフィルをサポート（実験的） [#37119](https://github.com/pingcap/tidb/issues/37119) @[zimulala](https://github.com/zimulala) - `CURDATE()`を列のデフォルト値として使用することをサポートします [#38356](https://github.com/pingcap/tidb/issues/38356) @[CbcWestwolf](https://github.com/CbcWestwolf) - `partial order prop push down`が LIST 型のパーティションテーブルをサポートするようになりました [#40273](https://github.com/pingcap/tidb/issues/40273) @[winoros](https://github.com/winoros) - - オプティマイザーのヒントと実行計画のバインディング間の競合に関するエラーメッセージを追加 [#40910](https://github.com/pingcap/tidb/issues/40910) @[Reminiscent](https://github.com/Reminiscent) + - オプティマイザのヒントと実行計画のバインディング間の競合に関するエラーメッセージを追加 [#40910](https://github.com/pingcap/tidb/issues/40910) @[Reminiscent](https://github.com/Reminiscent) - プランキャッシュ戦略を最適化し、一部のシナリオでプランキャッシュを使用する際に最適でないプランを回避する[#40312](https://github.com/pingcap/tidb/pull/40312) [#40218](https://github.com/pingcap/tidb/pull/40218) [#40280](https://github.com/pingcap/tidb/pull/40280) [#41136](https://github.com/pingcap/tidb/pull/41136) [#40686](https://github.com/pingcap/tidb/pull/40686) @[qw4990](https://github.com/qw4990) - メモリリークとパフォーマンスの低下を避けるために、期限切れの領域キャッシュを定期的にクリアします [#40461](https://github.com/pingcap/tidb/issues/40461) @[sticnarf](https://github.com/sticnarf) - `MODIFY COLUMN`はパーティションテーブルではサポートされていません [#39915](https://github.com/pingcap/tidb/issues/39915) @[wjhuang2016](https://github.com/wjhuang2016) diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index 4dcc05567864e..a9f087dc3f1a2 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -131,7 +131,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone バージョン7.0.0では、TiDBは統計情報の収集ロジックをさらに最適化し、収集時間を約25%短縮しました。この最適化により、大規模データベースクラスタの運用効率と安定性が向上し、統計情報の収集がクラスタのパフォーマンスに与える影響が軽減されます。 -- MPP 最適化のための新しいオプティマイザーヒントを追加 [#39710](https://github.com/pingcap/tidb/issues/39710) @[Reminiscent](https://github.com/Reminiscent) +- MPP 最適化のための新しいオプティマイザヒントを追加 [#39710](https://github.com/pingcap/tidb/issues/39710) @[Reminiscent](https://github.com/Reminiscent) バージョン7.0.0では、TiDBはMPP実行計画の生成に影響を与える一連のオプティマイザヒントを追加しました。 @@ -144,7 +144,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone 詳細については、[ドキュメント](/optimizer-hints.md)を参照してください。 -- オプティマイザーのヒントは、結合メソッドと結合順序の指定をサポートします [#36600](https://github.com/pingcap/tidb/issues/36600) @[Reminiscent](https://github.com/Reminiscent) +- オプティマイザのヒントは、結合メソッドと結合順序の指定をサポートします [#36600](https://github.com/pingcap/tidb/issues/36600) @[Reminiscent](https://github.com/Reminiscent) バージョン7.0.0では、オプティマイザヒント[`LEADING()`](/optimizer-hints.md#leadingt1_name--tl_name-)結合方法に影響を与えるヒントと併用できるようになり、両者の動作は互換性があります。複数テーブル結合の場合、最適な結合方法と結合順序を効果的に指定できるため、実行計画に対するオプティマイザヒントの制御が強化されます。 diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 4a24396be239a..890431d6b157d 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -35,7 +35,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 v7.0.0 では、クエリパフォーマンスを最適化するための実験的機能として、 TiFlashに遅延マテリアライゼーションが導入されました。この機能はデフォルトでは無効になっています ( [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)システム変数はデフォルトで`OFF`に設定されます)。フィルタ条件 ( `WHERE`句) を含む`SELECT`ステートメントを処理する場合、 TiFlash はクエリに必要な列からすべてのデータを読み取り、クエリ条件に基づいてデータをフィルタリングおよび集計します。遅延マテリアライゼーションを有効にすると、TiDB はフィルタ条件の一部を TableScan 演算子にプッシュダウンすることをサポートします。つまり、 TiFlash は最初に TableScan 演算子にプッシュダウンされるフィルタ条件に関連する列データをスキャンし、条件を満たす行をフィルタリングしてから、これらの行の他の列データをスキャンしてさらに計算を行うため、IO スキャンとデータ処理の計算が削減されます。 - バージョン7.1.0以降、 TiFlashの遅延マテリアライゼーション機能が一般提供され、デフォルトで有効化されています（システム変数[`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)はデフォルトで`ON`に設定されています）。TiDBオプティマイザーは、クエリの統計情報とフィルター条件に基づいて、TableScan演算子にプッシュダウンするフィルターを決定します。 + バージョン7.1.0以降、 TiFlashの遅延マテリアライゼーション機能が一般提供され、デフォルトで有効化されています（システム変数[`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)はデフォルトで`ON`に設定されています）。TiDBオプティマイザは、クエリの統計情報とフィルター条件に基づいて、TableScan演算子にプッシュダウンするフィルターを決定します。 詳細については[ドキュメント](/tiflash/tiflash-late-materialization.md)を参照してください。 @@ -142,7 +142,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 TiDB v6.5.0以降、 `INSERT INTO SELECT`ステートメントの`SELECT`の句（分析クエリ）をTiFlashにプッシュダウンできるようになりました。これにより、 TiFlashクエリの結果を`INSERT INTO`の句で指定されたTiDBテーブルに簡単に保存し、さらに分析することができます。これは、結果のキャッシュ（つまり、結果のマテリアライゼーション）として機能します。 - この機能はバージョン7.1.0で一般公開されています。`INSERT INTO SELECT`の`SELECT`句の実行中、オプティマイザーは、 [SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定できます。そのため、実験的段階で導入された`tidb_enable_tiflash_read_for_write_stmt`システム変数は非推奨となりました。TiFlashの`INSERT INTO SELECT`文の計算規則は`STRICT SQL Mode`要件を満たしていないため、TiDBは、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合にのみ、 `INSERT INTO SELECT`文の`SELECT`句をTiFlashにプッシュダウンすることを許可します。つまり、 `sql_mode`値に`STRICT_TRANS_TABLES`と`STRICT_ALL_TABLES`が含まれません。 + この機能はバージョン7.1.0で一般公開されています。`INSERT INTO SELECT`の`SELECT`句の実行中、オプティマイザは、 [SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定できます。そのため、実験的段階で導入された`tidb_enable_tiflash_read_for_write_stmt`システム変数は非推奨となりました。TiFlashの`INSERT INTO SELECT`文の計算規則は`STRICT SQL Mode`要件を満たしていないため、TiDBは、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合にのみ、 `INSERT INTO SELECT`文の`SELECT`句をTiFlashにプッシュダウンすることを許可します。つまり、 `sql_mode`値に`STRICT_TRANS_TABLES`と`STRICT_ALL_TABLES`が含まれません。 詳細については[ドキュメント](/tiflash/tiflash-results-materialization.md)を参照してください。 @@ -242,7 +242,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | 変数名 | タイプを変更 | 説明 | | --------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 非推奨 | デフォルト値を`OFF`から`ON`に変更します。 [`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-new-in-v50)の場合、オプティマイザーは[SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定します。 | +| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 非推奨 | デフォルト値を`OFF`から`ON`に変更します。 [`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-new-in-v50)の場合、オプティマイザは[SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定します。 | | [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | | [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | | `tidb_ddl_distribute_reorg` | 削除済み | この変数の名前は[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)に変更されます。 | diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index e09042d1ac0ee..6ab6eda49ea06 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -99,7 +99,7 @@ TiDB バージョン: 7.1.6 - ビュー定義でサブクエリが列定義として使用されている場合、 `information_schema.columns`を使用して列情報を取得すると警告1356が返される問題を修正しました。 [＃54343](https://github.com/pingcap/tidb/issues/54343) @[lance6716](https://github.com/lance6716) - クエリ条件`column IS NULL` で一意インデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 [＃56116](https://github.com/pingcap/tidb/issues/56116) @[hawkingrei](https://github.com/hawkingrei) - クラスター化インデックスを述語として使用すると`SELECT INTO OUTFILE`機能しない問題を修正[＃42093](https://github.com/pingcap/tidb/issues/42093) @[qw4990](https://github.com/qw4990) - - オプティマイザーヒント使用時に誤った警告情報が表示される問題を修正しました [＃53767](https://github.com/pingcap/tidb/issues/53767) @[hawkingrei](https://github.com/hawkingrei) + - オプティマイザヒント使用時に誤った警告情報が表示される問題を修正しました [＃53767](https://github.com/pingcap/tidb/issues/53767) @[hawkingrei](https://github.com/hawkingrei) - 同期負荷QPSモニタリングメトリックが正しくない問題を修正[＃53558](https://github.com/pingcap/tidb/issues/53558) @[hawkingrei](https://github.com/hawkingrei) - `CREATE OR REPLACE VIEW`同時に実行すると`table doesn't exist`エラーが発生する可能性がある問題を修正 [＃53673](https://github.com/pingcap/tidb/issues/53673) @[tangenta](https://github.com/tangenta) - `RESTORE`ステートメントを使用して`AUTO_ID_CACHE=1`のテーブルを復元すると`Duplicate entry`エラーが発生する可能性がある問題を修正しました [＃52680](https://github.com/pingcap/tidb/issues/52680) @[tiancaiamao](https://github.com/tiancaiamao) diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index b0f1eab38ed2e..a5d024d8f52c9 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -75,11 +75,11 @@ TiDB バージョン: 7.2.0 詳細については、[ドキュメント](/sql-plan-management.md)を参照してください。 -- オプティマイザー修正制御メカニズムを導入して、オプティマイザーの動作をきめ細かく制御できるようにします [#43169](https://github.com/pingcap/tidb/issues/43169) @[time-and-fate](https://github.com/time-and-fate) +- オプティマイザ修正制御メカニズムを導入して、オプティマイザの動作をきめ細かく制御できるようにします [#43169](https://github.com/pingcap/tidb/issues/43169) @[time-and-fate](https://github.com/time-and-fate) より適切な実行計画を生成するため、TiDB オプティマイザの動作は製品のバージョンアップごとに進化しています。しかし、特定のシナリオでは、変更によってパフォーマンスが低下する場合があります。TiDB v7.2.0 では、オプティマイザの細かい動作を制御できるオプティマイザ修正コントロールが導入されました。これにより、一部の新しい変更をロールバックしたり、制御したりすることが可能になります。 - 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべてオプティマ[オプティマイザー修正コントロール](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1つ以上の動作の目標値を設定できます。 + 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべてオプティマ[オプティマイザ修正コントロール](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1つ以上の動作の目標値を設定できます。 オプティマイザ修正制御メカニズムを使用すると、TiDBオプティマイザをきめ細かく制御できます。これにより、アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段が提供され、TiDBの安定性が向上します。 diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 2c8ff30143943..eb4119ff576af 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -37,7 +37,7 @@ TiDB バージョン: 7.4.0 v7.0.0では、 TiFlashは実験的機能として、分散ストレージおよびコンピューティングアーキテクチャを導入しました。一連の改良を経て、v7.4.0以降、 TiFlashの分散ストレージおよびコンピューティングアーキテクチャがGAとなります。 - このアーキテクチャでは、 TiFlashノードは2種類（コンピューティングノードと書き込みノード）に分かれており、S3 APIと互換性のあるオブジェクトストレージをサポートします。どちらのノードも、コンピューティング容量またはストレージ容量を個別に拡張できます。分散ストレージおよびコンピューティングアーキテクチャでは、 TiFlashレプリカの作成、データのクエリ、オプティマイザーヒントの指定など、結合ストレージおよびコンピューティングアーキテクチャと同様にTiFlashを使用できます。 + このアーキテクチャでは、 TiFlashノードは2種類（コンピューティングノードと書き込みノード）に分かれており、S3 APIと互換性のあるオブジェクトストレージをサポートします。どちらのノードも、コンピューティング容量またはストレージ容量を個別に拡張できます。分散ストレージおよびコンピューティングアーキテクチャでは、 TiFlashレプリカの作成、データのクエリ、オプティマイザヒントの指定など、結合ストレージおよびコンピューティングアーキテクチャと同様にTiFlashを使用できます。 TiFlash**の分散ストレージおよびコンピューティングアーキテクチャ**と**結合ストレージおよびコンピューティングアーキテクチャ**は、同じクラスター内で使用したり、相互に変換したりすることはできません。TiFlashをデプロイする際に、使用するアーキテクチャを設定できます。 diff --git a/releases/release-7.5.3.md b/releases/release-7.5.3.md index eaf6f8b25c70f..5d683fa2b29da 100644 --- a/releases/release-7.5.3.md +++ b/releases/release-7.5.3.md @@ -68,7 +68,7 @@ TiDB バージョン: 7.5.3 - `CREATE OR REPLACE VIEW`同時に実行すると`table doesn't exist`エラーが発生する可能性がある問題を修正 [＃53673](https://github.com/pingcap/tidb/issues/53673) @[tangenta](https://github.com/tangenta) - データ変更操作を含むトランザクションで仮想列を持つテーブルをクエリすると、TiDB が誤ったクエリ結果を返す可能性がある問題を修正しました [＃53951](https://github.com/pingcap/tidb/issues/53951) @[qw4990](https://github.com/qw4990) - `SELECT DISTINCT CAST(col AS DECIMAL), CAST(col AS SIGNED) FROM ...`クエリを実行すると誤った結果が返される可能性がある問題を修正[＃53726](https://github.com/pingcap/tidb/issues/53726) @[hawkingrei](https://github.com/hawkingrei) - - オプティマイザーヒント使用時に誤った警告情報が表示される問題を修正しました [＃53767](https://github.com/pingcap/tidb/issues/53767) @[hawkingrei](https://github.com/hawkingrei) + - オプティマイザヒント使用時に誤った警告情報が表示される問題を修正しました [＃53767](https://github.com/pingcap/tidb/issues/53767) @[hawkingrei](https://github.com/hawkingrei) - 場合によっては無効な列タイプ`DECIMAL(0,0)`が作成される可能性がある問題を修正[＃53779](https://github.com/pingcap/tidb/issues/53779) @[tangenta](https://github.com/tangenta) - `memory_quota`ヒントがサブクエリで機能しない可能性がある問題を修正しました [＃53834](https://github.com/pingcap/tidb/issues/53834) @[qw4990](https://github.com/qw4990) - JSON関連の関数がMySQLと矛盾するエラーを返す場合がある問題を修正[＃53799](https://github.com/pingcap/tidb/issues/53799) @[dveeden](https://github.com/dveeden) diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md index f7c5afca7f738..28edf62ef7d8f 100644 --- a/releases/release-7.6.0.md +++ b/releases/release-7.6.0.md @@ -357,7 +357,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - `ENUM`型の列を結合キーとして使用した場合にクエリ結果が正しくない問題を修正 [#48991](https://github.com/pingcap/tidb/issues/48991) @[winoros](https://github.com/winoros) - メモリ制限を超えると、CTE を含むクエリが予期せずスタックする問題を修正 [#49096](https://github.com/pingcap/tidb/issues/49096) @[AilinKid](https://github.com/AilinKid) - TiDBサーバーが監査ログ用のEnterpriseプラグイン使用時に大量のリソースを消費する可能性がある問題を修正 [#49273](https://github.com/pingcap/tidb/issues/49273) @[lcwangchao](https://github.com/lcwangchao) - - 特定のシナリオでオプティマイザーがTiFlash選択パスを DUAL テーブルに誤って変換する問題を修正 [#49285](https://github.com/pingcap/tidb/issues/49285) @[AilinKid](https://github.com/AilinKid) + - 特定のシナリオでオプティマイザがTiFlash選択パスを DUAL テーブルに誤って変換する問題を修正 [#49285](https://github.com/pingcap/tidb/issues/49285) @[AilinKid](https://github.com/AilinKid) - `UPDATE`または`DELETE`ステートメントに`WITH RECURSIVE` CTE が含まれている場合、誤った結果が生じる可能性がある問題を修正しました [#48969](https://github.com/pingcap/tidb/issues/48969) @[winoros](https://github.com/winoros) - IndexHashJoin演算子を含むクエリがメモリ使用量`tidb_mem_quota_query`超えると停止する問題を修正しました [#49033](https://github.com/pingcap/tidb/issues/49033) @[XuHuaiyu](https://github.com/XuHuaiyu) - 非厳格モード ( `sql_mode = ''` ) で`INSERT`実行中に切り捨てが発生し、エラーが報告される問題を修正しました [#49369](https://github.com/pingcap/tidb/issues/49369) @[tiancaiamao](https://github.com/tiancaiamao) diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md index 0f0aab7728c77..6bb4c2ce71009 100644 --- a/releases/release-8.0.0.md +++ b/releases/release-8.0.0.md @@ -85,7 +85,7 @@ TiDB バージョン: 8.0.0 詳細については、[ドキュメント](/sql-prepared-plan-cache.md)を参照してください。 -- オプティマイザーが多値インデックスのサポートを強化[#47759](https://github.com/pingcap/tidb/issues/47759) [#46539](https://github.com/pingcap/tidb/issues/46539) @[Arenatlx](https://github.com/Arenatlx)@[time-and-fate](https://github.com/time-and-fate) +- オプティマイザが多値インデックスのサポートを強化[#47759](https://github.com/pingcap/tidb/issues/47759) [#46539](https://github.com/pingcap/tidb/issues/46539) @[Arenatlx](https://github.com/Arenatlx)@[time-and-fate](https://github.com/time-and-fate) TiDB v6.6.0 では[多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)が導入され、JSON データ型のクエリパフォーマンスが向上しました。v8.0.0 では、オプティマイザが多値インデックスのサポートを強化し、複雑なシナリオでクエリを最適化するために、それらを正しく識別して利用できるようになりました。 @@ -282,7 +282,7 @@ TiDB バージョン: 8.0.0 | [`tidb_load_binding_timeout`](/system-variables.md#tidb_load_binding_timeout-new-in-v800) | 新しく追加された | バインディングの読み込みタイムアウトを制御します。バインディングの読み込み実行時間がこの値を超えると、読み込みが停止します。 | | [`tidb_low_resolution_tso_update_interval`](/system-variables.md#tidb_low_resolution_tso_update_interval-new-in-v800) | 新しく追加された | TiDB [キャッシュタイムスタンプ](/system-variables.md#tidb_low_resolution_tso)スタンプを更新する間隔を制御します。 | | [`tidb_opt_ordering_index_selectivity_ratio`](/system-variables.md#tidb_opt_ordering_index_selectivity_ratio-new-in-v800) | 新しく追加された | SQL ステートメントに`ORDER BY`および`ORDER BY` } 句が存在するものの、インデックスでカバーされていないフィルタ条件がある場合に、SQL ステートメント`LIMIT`に一致するインデックスの推定行数を制御します。デフォルト値は`-1`で、このシステム変数を無効にすることを意味します。 | -| [`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800) | 新しく追加された | オプティマイザーが現在のセッションでクエリ最適化のために[不可視インデックス](/sql-statements/sql-statement-create-index.md#invisible-index)を選択できるかどうかを制御します。変数が`ON`に設定されている場合、オプティマイザーはセッション内のクエリ最適化のために不可視インデックスを選択できます。 | +| [`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800) | 新しく追加された | オプティマイザが現在のセッションでクエリ最適化のために[不可視インデックス](/sql-statements/sql-statement-create-index.md#invisible-index)を選択できるかどうかを制御します。変数が`ON`に設定されている場合、オプティマイザはセッション内のクエリ最適化のために不可視インデックスを選択できます。 | | [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) | 新しく追加された | スキーマ情報のキャッシュに使用できるメモリの上限を制御し、メモリの過剰使用を防ぎます。この機能を有効にすると、LRUアルゴリズムを使用して必要なテーブルをキャッシュし、スキーマ情報によって占有されるメモリを効果的に削減します。 | ### コンフィグレーションファイルパラメータ {#configuration-file-parameters} diff --git a/releases/release-8.1.1.md b/releases/release-8.1.1.md index 346c439cdae25..f8dfd949a4469 100644 --- a/releases/release-8.1.1.md +++ b/releases/release-8.1.1.md @@ -86,7 +86,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - TiProxy とリソースグループを使用するときに、各リソースグループの接続数が正しくない問題を修正しました。 [＃54545](https://github.com/pingcap/tidb/issues/54545) @[YangKeao](https://github.com/YangKeao) - 再帰CTE でビューの使用が機能しない問題を修正 [＃49721](https://github.com/pingcap/tidb/issues/49721) @[hawkingrei](https://github.com/hawkingrei) - 大規模並列処理 (MPP) で`final` AggMode と`non-final` AggMode が共存できない問題を修正しました [＃51362](https://github.com/pingcap/tidb/issues/51362) @[AilinKid](https://github.com/AilinKid) - - オプティマイザーヒント使用時に誤った警告情報が表示される問題を修正しました [＃53767](https://github.com/pingcap/tidb/issues/53767) @[hawkingrei](https://github.com/hawkingrei) + - オプティマイザヒント使用時に誤った警告情報が表示される問題を修正しました [＃53767](https://github.com/pingcap/tidb/issues/53767) @[hawkingrei](https://github.com/hawkingrei) - `HashJoin`または`IndexLookUp`演算子が`Apply`演算子の駆動側サブノードである場合に`memTracker`切り離されないことで発生する異常に高いメモリ使用量の問題を修正しました。 [＃54005](https://github.com/pingcap/tidb/issues/54005) @[XuHuaiyu](https://github.com/XuHuaiyu) - 場合によっては無効な列タイプ`DECIMAL(0,0)`が作成される可能性がある問題を修正[＃53779](https://github.com/pingcap/tidb/issues/53779) @[tangenta](https://github.com/tangenta) - `(*PointGetPlan).StatsInfo()` の実行中に発生する可能性のあるデータ競合の問題を修正しました [＃43339](https://github.com/pingcap/tidb/issues/43339) @[qw4990](https://github.com/qw4990) [＃49803](https://github.com/pingcap/tidb/issues/49803) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 43c20658106c3..b44f7cb5ad396 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -304,7 +304,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - 大量のデータをスキャンする際のBatchCopタスク構築の効率を最適化する[#55915](https://github.com/pingcap/tidb/issues/55915) [#55413](https://github.com/pingcap/tidb/issues/55413) @[wshwsh12](https://github.com/wshwsh12) - トランザクションのバッファを最適化して、トランザクション内の書き込みレイテンシーと TiDB の CPU 使用率を削減します [#55287](https://github.com/pingcap/tidb/issues/55287) @[you06](https://github.com/you06) - システム変数`tidb_dml_type`が`"bulk"`に設定されている場合の DML ステートメントの実行パフォーマンスを最適化する [#50215](https://github.com/pingcap/tidb/issues/50215) @[ekexium](https://github.com/ekexium) - - [オプティマイザー修正制御 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザーが`estRows`の推定最小値を`1` 。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) + - [オプティマイザ修正制御 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザが`estRows`の推定最小値を`1` 。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) - [`mysql.tidb_runaway_queries`](/mysql-schema/mysql-schema.md#system-tables-related-to-runaway-queries)ログ テーブルに書き込み制御を追加し、多数の同時書き込みによって発生するオーバーヘッドを削減します [#54434](https://github.com/pingcap/tidb/issues/54434) @[HuSharp](https://github.com/HuSharp) - 内部テーブルに`Selection` 、 `Projection` 、または`Aggregation`演算子がある場合、デフォルトでインデックス結合をサポートします [#47233](https://github.com/pingcap/tidb/issues/47233) @[winoros](https://github.com/winoros) - 特定のシナリオにおける`DELETE`操作のために TiKV から取得する列の詳細の数を減らし、これらの操作のリソースオーバーヘッドを削減します [#38911](https://github.com/pingcap/tidb/issues/38911) @[winoros](https://github.com/winoros) diff --git a/releases/release-pre-ga.md b/releases/release-pre-ga.md index 6ed131b5e1070..55027485e891d 100644 --- a/releases/release-pre-ga.md +++ b/releases/release-pre-ga.md @@ -1,6 +1,6 @@ --- title: Pre-GA release notes -summary: 2017年8月30日にリリースされたTiDBのプレGAリリースは、MySQLとの互換性、SQLの最適化、安定性、そしてパフォーマンスに重点を置いています。TiDBでは、SQLクエリオプティマイザーの強化、MySQLとの互換性、JSON型のサポート、そしてメモリ消費量の削減が導入されています。Placement Driver（PD）は手動でのリーダー変更をサポートするようになり、TiKVはRaftログストレージに専用のRocksDBを使用することでパフォーマンスを向上させています。Sparkベータリリース向けのTiDBコネクタは、述語プッシュダウン、集計プッシュダウン、および範囲プルーニングを実装し、TPC-Hクエリの実行を可能にします。 +summary: 2017年8月30日にリリースされたTiDBのプレGAリリースは、MySQLとの互換性、SQLの最適化、安定性、そしてパフォーマンスに重点を置いています。TiDBでは、SQLクエリオプティマイザの強化、MySQLとの互換性、JSON型のサポート、そしてメモリ消費量の削減が導入されています。Placement Driver（PD）は手動でのリーダー変更をサポートするようになり、TiKVはRaftログストレージに専用のRocksDBを使用することでパフォーマンスを向上させています。Sparkベータリリース向けのTiDBコネクタは、述語プッシュダウン、集計プッシュダウン、および範囲プルーニングを実装し、TPC-Hクエリの実行を可能にします。 --- # プレGAリリースノート {#pre-ga-release-notes} @@ -9,7 +9,7 @@ summary: 2017年8月30日にリリースされたTiDBのプレGAリリースは ## TiDB {#tidb} -- SQL クエリ オプティマイザー: +- SQL クエリ オプティマイザ: - コストモデルを調整する - インデックススキャンを使用して、両側に異なる型を持つ`compare`式を持つ`where`句を処理します。 - 貪欲アルゴリズムに基づく結合したテーブルの再配置をサポート diff --git a/releases/release-rc.1.md b/releases/release-rc.1.md index eeabd54b13e4b..c67801fd96675 100644 --- a/releases/release-rc.1.md +++ b/releases/release-rc.1.md @@ -23,13 +23,13 @@ summary: TiDB RC1は2016年12月23日にリリースされました。アップ ## TiDB {#tidb} -- SQL クエリ オプティマイザーでは次の機能が追加または改善されています。 +- SQL クエリ オプティマイザでは次の機能が追加または改善されています。 - 熱心な集約 - さらに詳しい`EXPLAIN`情報 - `UNION`演算子の並列化 - サブクエリパフォーマンスの最適化 - 条件付きプッシュダウンの最適化 - - コストベースオプティマイザー（CBO）フレームワークの最適化 + - コストベースオプティマイザ（CBO）フレームワークの最適化 - 時間関連のデータ型の実装がリファクタリングされ、MySQL との互換性が向上しました。 - MySQL のより多くの組み込み関数がサポートされます。 - `add index`文目の速度が向上します。 diff --git a/releases/release-rc.2.md b/releases/release-rc.2.md index 72edc72b4597f..39bd7a1a09ebe 100644 --- a/releases/release-rc.2.md +++ b/releases/release-rc.2.md @@ -5,14 +5,14 @@ summary: 2017年3月1日にリリースされたTiDB RC2は、MySQLとの互換 # TiDB RC2 リリースノート {#tidb-rc2-release-notes} -2017年3月1日、TiDB RC2がリリースされました！このリリースでは、MySQLとの互換性、SQLクエリオプティマイザー、システムの安定性とパフォーマンスの向上に重点が置かれています。さらに、新しい権限管理メカニズムが追加され、ユーザーはMySQLの権限管理システムと同様にデータアクセスを制御できるようになりました。 +2017年3月1日、TiDB RC2がリリースされました！このリリースでは、MySQLとの互換性、SQLクエリオプティマイザ、システムの安定性とパフォーマンスの向上に重点が置かれています。さらに、新しい権限管理メカニズムが追加され、ユーザーはMySQLの権限管理システムと同様にデータアクセスを制御できるようになりました。 ## TiDB {#tidb} -- クエリオプティマイザー - - 列/インデックス統計を収集し、クエリオプティマイザーで使用します。 +- クエリオプティマイザ + - 列/インデックス統計を収集し、クエリオプティマイザで使用します。 - 相関サブクエリを最適化する - - コストベースオプティマイザー（CBO）フレームワークを最適化する + - コストベースオプティマイザ（CBO）フレームワークを最適化する - 一意のキー情報を使用して集約を排除する - 式評価フレームワークのリファクタリング - Distinct を GroupBy に変換する diff --git a/releases/release-rc.3.md b/releases/release-rc.3.md index c3c074e3fe8af..c4b2c4296e7b8 100644 --- a/releases/release-rc.3.md +++ b/releases/release-rc.3.md @@ -18,13 +18,13 @@ summary: 2017年6月16日にリリースされたTiDB RC3は、MySQLとの互換 ## TiDB {#tidb} -- SQL クエリ オプティマイザーでは次の機能が追加または改善されています。 +- SQL クエリ オプティマイザでは次の機能が追加または改善されています。 - 増分統計をサポート - `Merge Sort Join`オペレーターをサポート - `Index Lookup Join`オペレーターをサポート - `Optimizer Hint`構文をサポートする - `Scan` `Join`のメモリ消費`Aggregation`最適化する - - コストベースオプティマイザー（CBO）フレームワークを最適化する + - コストベースオプティマイザ（CBO）フレームワークを最適化する - リファクタリング`Expression` - より完全な権限管理をサポート - DDL加速 diff --git a/releases/release-rc.4.md b/releases/release-rc.4.md index 2427a8bed88f8..3e184371c7413 100644 --- a/releases/release-rc.4.md +++ b/releases/release-rc.4.md @@ -1,6 +1,6 @@ --- title: TiDB RC4 Release Notes -summary: TiDB RC4は、MySQLとの互換性、SQLの最適化、安定性、パフォーマンスに重点を置いてリリースされました。主な改善点としては、書き込みパフォーマンスの向上、クエリコストの見積もり精度の向上、TiSparkによるTiKV内のデータへのアクセスのサポートなどが挙げられます。詳細なアップデートには、SQLクエリオプティマイザーのリファクタリング、JSON型と操作のサポート、Placement Driverのスケジューラーの最適化が含まれます。TiKVは、RC分離レベル、ドキュメントストア、およびコプロセッサーのプッシュダウン関数のサポートを強化しました。TiSparkベータリリースには、予測プッシュダウン、集約プッシュダウン、範囲プルーニングが含まれており、TPC-Hクエリのフルセットを実行できます。 +summary: TiDB RC4は、MySQLとの互換性、SQLの最適化、安定性、パフォーマンスに重点を置いてリリースされました。主な改善点としては、書き込みパフォーマンスの向上、クエリコストの見積もり精度の向上、TiSparkによるTiKV内のデータへのアクセスのサポートなどが挙げられます。詳細なアップデートには、SQLクエリオプティマイザのリファクタリング、JSON型と操作のサポート、Placement Driverのスケジューラーの最適化が含まれます。TiKVは、RC分離レベル、ドキュメントストア、およびコプロセッサーのプッシュダウン関数のサポートを強化しました。TiSparkベータリリースには、予測プッシュダウン、集約プッシュダウン、範囲プルーニングが含まれており、TPC-Hクエリのフルセットを実行できます。 --- # TiDB RC4 リリースノート {#tidb-rc4-release-notes} @@ -10,7 +10,7 @@ summary: TiDB RC4は、MySQLとの互換性、SQLの最適化、安定性、パ ## ハイライト {#highlight} - パフォーマンスに関しては、書き込みパフォーマンスが大幅に向上し、コンピューティング タスクのスケジュール設定では、OLAP が OLTP に与える影響を回避するための優先順位付けがサポートされています。 -- オプティマイザーは、クエリ コストの見積もりがより正確になり、コストに基づいて`Join`の物理演算子が自動的に選択されるように改訂されました。 +- オプティマイザは、クエリ コストの見積もりがより正確になり、コストに基づいて`Join`の物理演算子が自動的に選択されるように改訂されました。 - MySQL との互換性を高めるために多くの機能強化が導入されました。 - OLAPビジネスシナリオをより適切にサポートするために、TiSparkがリリースされました。Sparkを使用してTiKVのデータにアクセスできるようになりました。 @@ -18,7 +18,7 @@ summary: TiDB RC4は、MySQLとの互換性、SQLの最適化、安定性、パ ### TiDB {#tidb} -- SQL クエリ オプティマイザーのリファクタリング: +- SQL クエリ オプティマイザのリファクタリング: - TopNクエリのサポート強化 - コストに基づいて`Join`物理演算子の自動選択をサポート - 投影除去の改善 diff --git a/sql-non-prepared-plan-cache.md b/sql-non-prepared-plan-cache.md index 9cce52ae3928a..81aed011a474f 100644 --- a/sql-non-prepared-plan-cache.md +++ b/sql-non-prepared-plan-cache.md @@ -16,7 +16,7 @@ TiDBは、 [ステートメント`Prepare` / `Execute`](/sql-prepared-plan-cache 1. 非プリペアドプランキャッシュを有効にすると、TiDBはまず抽象構文木（AST）に基づいてクエリをパラメータ化します。例えば、 `SELECT * FROM t WHERE b < 10 AND a = 1` `SELECT * FROM t WHERE b < ? and a = ?`としてパラメータ化されます。 2. 次に、TiDB はパラメータ化されたクエリを使用してプランキャッシュを検索します。 3. 再利用可能なプランが見つかった場合は、それが直接使用され、最適化フェーズはスキップされます。 -4. それ以外の場合、オプティマイザーは新しいプランを生成し、それをキャッシュに戻して、後続のクエリで再利用します。 +4. それ以外の場合、オプティマイザは新しいプランを生成し、それをキャッシュに戻して、後続のクエリで再利用します。 ## 使用法 {#usage} diff --git a/sql-physical-optimization.md b/sql-physical-optimization.md index 4a498505c6e3e..7a3827caf3843 100644 --- a/sql-physical-optimization.md +++ b/sql-physical-optimization.md @@ -1,6 +1,6 @@ --- title: SQL Physical Optimization -summary: 物理最適化は、論理実行計画に基づく物理実行計画を作成するコストベースのプロセスです。オプティマイザーは、データ統計、時間計算量、リソース消費量に基づいて、各演算子に最適な物理実装を選択します。これには、インデックスの選択、統計情報の収集、適切なインデックスの使用、個別のキーワード最適化、そして最適な実行計画選択のためのコストモデルが含まれます。 +summary: 物理最適化は、論理実行計画に基づく物理実行計画を作成するコストベースのプロセスです。オプティマイザは、データ統計、時間計算量、リソース消費量に基づいて、各演算子に最適な物理実装を選択します。これには、インデックスの選択、統計情報の収集、適切なインデックスの使用、個別のキーワード最適化、そして最適な実行計画選択のためのコストモデルが含まれます。 --- # SQL物理最適化 {#sql-physical-optimization} diff --git a/sql-plan-management.md b/sql-plan-management.md index b550964d20645..2225f4ec691ba 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -100,7 +100,7 @@ USING INSERT /*+ use_index(@sel_1 pre_orders, idx_created) */ INTO orders SELECT * FROM pre_orders WHERE status = 'VALID' AND created <= (NOW() - INTERVAL 1 HOUR); ``` -実行計画のバインディングを作成する際にスコープを指定しない場合、デフォルトのスコープはSESSIONです。TiDBオプティマイザーは、バインドされたSQL文を正規化し、システムテーブルに格納します。SQLクエリの処理時に、正規化された文がシステムテーブル内のバインドされたSQL文のいずれかと一致し、システム変数`tidb_use_plan_baselines`が`on` （デフォルト値は`on` ）に設定されている場合、TiDBはこの文に対応するオプティマイザーヒントを使用します。一致可能な実行計画が複数ある場合、オプティマイザーは最もコストの低いプランを選択してバインドします。 +実行計画のバインディングを作成する際にスコープを指定しない場合、デフォルトのスコープはSESSIONです。TiDBオプティマイザは、バインドされたSQL文を正規化し、システムテーブルに格納します。SQLクエリの処理時に、正規化された文がシステムテーブル内のバインドされたSQL文のいずれかと一致し、システム変数`tidb_use_plan_baselines`が`on` （デフォルト値は`on` ）に設定されている場合、TiDBはこの文に対応するオプティマイザヒントを使用します。一致可能な実行計画が複数ある場合、オプティマイザは最もコストの低いプランを選択してバインドします。 `Normalization` とは、SQL文内の定数を変数パラメータに変換し、クエリで参照されるテーブルのデータベースを明示的に指定する処理です。SQL文内のスペースと改行は標準化された方法で処理されます。次の例をご覧ください。 @@ -172,7 +172,7 @@ SELECT * FROM bookshop . users WHERE balance > ? > +-------------------------------------------------+------------------------------------------------------------------------+------------+---------+-------------------------+-------------------------+---------+--------------------+--------+------------------------------------------------------------------+-------------+ > ``` -SQL ステートメントに GLOBAL スコープと SESSION スコープの両方のバインドされた実行計画がある場合、オプティマイザーは SESSION バインドを検出すると GLOBAL スコープのバインドされた実行計画を無視するため、SESSION スコープ内のこのステートメントのバインドされた実行計画は GLOBAL スコープの実行計画を保護します。 +SQL ステートメントに GLOBAL スコープと SESSION スコープの両方のバインドされた実行計画がある場合、オプティマイザは SESSION バインドを検出すると GLOBAL スコープのバインドされた実行計画を無視するため、SESSION スコープ内のこのステートメントのバインドされた実行計画は GLOBAL スコープの実行計画を保護します。 例えば： @@ -783,7 +783,7 @@ SELECT * FROM t WHERE a < 100 AND b < 100; CREATE GLOBAL BINDING for SELECT * FROM t WHERE a < 100 AND b < 100 USING SELECT * FROM t use index(a) WHERE a < 100 AND b < 100; ``` -上記のクエリが再度実行されると、オプティマイザーはインデックス`a` (上記で作成されたバインディングの影響を受けます) を選択して、クエリ時間を短縮します。 +上記のクエリが再度実行されると、オプティマイザはインデックス`a` (上記で作成されたバインディングの影響を受けます) を選択して、クエリ時間を短縮します。 テーブル`t`で挿入と削除が実行されるにつれて、条件`a < 100`を満たす行の数が増加し、条件`b < 100`を満たす行の数が減少すると仮定します。この時点で、バインディングでインデックス`a`を使用することは、もはや最適なプランではない可能性があります。 @@ -807,9 +807,9 @@ CREATE GLOBAL BINDING for SELECT * FROM t WHERE a < 100 AND b < 100 USING SELECT | ヒント | 説明 | | :------------------------ | :----------------------------------------------- | | `memory_quota` | クエリに使用できる最大メモリ。 | - | `use_toja` | オプティマイザーがサブクエリを結合に変換するかどうか。 | - | `use_cascades` | カスケード オプティマイザーを使用するかどうか。 | - | `no_index_merge` | オプティマイザーがテーブルを読み取るためのオプションとしてインデックスマージを使用するかどうか。 | + | `use_toja` | オプティマイザがサブクエリを結合に変換するかどうか。 | + | `use_cascades` | カスケード オプティマイザを使用するかどうか。 | + | `no_index_merge` | オプティマイザがテーブルを読み取るためのオプションとしてインデックスマージを使用するかどうか。 | | `read_consistent_replica` | テーブルの読み取り時にFollower Read を強制的に有効にするかどうか。 | | `max_execution_time` | クエリの最長時間。 | diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index 7984f2efeb67f..f73807eefb256 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -190,12 +190,12 @@ mysql> show stats_meta; ## `PLAN REPLAYER CAPTURE`を使用してターゲットプランをキャプチャします {#use-plan-replayer-capture-to-capture-target-plans} -TiDBの実行計画を特定する場合、対象となるSQL文と実行計画がクエリ内にまれにしか出現しないため、 `PLAN REPLAYER`を使用して文とプランを直接取得できない場合があります。このような場合、 `PLAN REPLAYER CAPTURE`を使用すると、対象となるSQL文と実行計画のオプティマイザー情報を取得できます。 +TiDBの実行計画を特定する場合、対象となるSQL文と実行計画がクエリ内にまれにしか出現しないため、 `PLAN REPLAYER`を使用して文とプランを直接取得できない場合があります。このような場合、 `PLAN REPLAYER CAPTURE`を使用すると、対象となるSQL文と実行計画のオプティマイザ情報を取得できます。 `PLAN REPLAYER CAPTURE`は主に次の機能があります。 - 対象となるSQL文と対象実行計画のダイジェストを事前にTiDBクラスタに登録し、対象クエリとのマッチングを開始します。 -- ターゲット クエリが正常に一致すると、そのオプティマイザー関連の情報を直接キャプチャし、ZIP ファイルとしてエクスポートします。 +- ターゲット クエリが正常に一致すると、そのオプティマイザ関連の情報を直接キャプチャし、ZIP ファイルとしてエクスポートします。 - 一致した SQL と実行計画ごとに、情報は 1回だけキャプチャされます。 - システムテーブルを通じて、進行中の一致するタスクと生成されたファイルを表示します。 - 履歴ファイルを定期的にクリーンアップします。 diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index 62f4558ff9f9f..3e9b72a75dc1f 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -10,7 +10,7 @@ TiDBは、 `Prepare`と`Execute`クエリの実行計画のキャッシュをサ - プロトコル機能`COM_STMT_PREPARE`および`COM_STMT_EXECUTE`使用。 - SQL ステートメント`PREPARE`と`EXECUTE`を使用します。 -TiDB オプティマイザーは、これら2種類のクエリを同じ方法で処理します。準備時に、パラメータ化されたクエリは AST (抽象構文ツリー) に解析され、キャッシュされます。その後の実行時に、保存された AST と特定のパラメータ値に基づいて実行計画が生成されます。 +TiDB オプティマイザは、これら2種類のクエリを同じ方法で処理します。準備時に、パラメータ化されたクエリは AST (抽象構文ツリー) に解析され、キャッシュされます。その後の実行時に、保存された AST と特定のパラメータ値に基づいて実行計画が生成されます。 実行プランキャッシュが有効な場合、最初の実行では、各`Prepare`ごとに現在のクエリが実行プランキャッシュを使用できるかどうかが確認され、使用できる場合は、生成された実行計画がLRU（Least Recently Used）リンクリストで実装されたキャッシュに格納されます。後続の`Execute`クエリでは、キャッシュから実行計画が取得され、その可用性が確認されます。確認が成功した場合、実行計画生成のステップはスキップされます。そうでない場合は、実行計画が再生成され、キャッシュに保存されます。 @@ -56,7 +56,7 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで - 実行計画は、キャッシュされているかどうかに関わらず、SQLバインディングの影響を受けます。キャッシュされていない実行計画（最初の`Execute` ）は、既存のSQLバインディングの影響を受けます。キャッシュされている実行計画は、新しいSQLバインディングが作成されると無効になります。 - キャッシュされたプランは、統計、最適化ルール、式によるブロックリストのプッシュダウンの変更の影響を受けません。 - `Execute`のパラメータが異なることを考慮し、実行プランキャッシュは、適応性を確保するために、特定のパラメータ値に密接に関連する一部の積極的なクエリ最適化手法を禁止します。これにより、クエリプランが特定のパラメータ値に対して最適にならない可能性があります。例えば、クエリのフィルタ条件が`where a > ? And a < ?`で、最初の`Execute`ステートメントのパラメータがそれぞれ`2`と`1`あるとします。これらの 2つのパラメータが次回の実行時に`1`と`2`なる可能性があることを考慮すると、オプティマイザは現在のパラメータ値に固有の最適な`TableDual`実行計画を生成しません。 -- キャッシュの無効化と削除を考慮しない場合、実行プランキャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行計画が生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザーは最適な`IndexScan`実行計画を生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プランキャッシュがあるため、以前に生成された`IndexScan`を使用して実行されます。そのため、実行プランキャッシュは、クエリが単純 (コンパイル率が高い) で実行計画が比較的固定されているアプリケーションシナリオに適しています。 +- キャッシュの無効化と削除を考慮しない場合、実行プランキャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行計画が生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザは最適な`IndexScan`実行計画を生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プランキャッシュがあるため、以前に生成された`IndexScan`を使用して実行されます。そのため、実行プランキャッシュは、クエリが単純 (コンパイル率が高い) で実行計画が比較的固定されているアプリケーションシナリオに適しています。 バージョン6.1.0以降、実行プランキャッシュはデフォルトで有効になっています。プリペアドプランキャッシュはシステム変数[`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)を介して制御できます。 diff --git a/sql-statements/sql-statement-alter-index.md b/sql-statements/sql-statement-alter-index.md index 41c70de511ad5..9fc65d95e71ba 100644 --- a/sql-statements/sql-statement-alter-index.md +++ b/sql-statements/sql-statement-alter-index.md @@ -47,7 +47,7 @@ SHOW CREATE TABLE t1; 1 row in set (0.00 sec) ``` -オプティマイザーは**不可視インデックス**`c1`を使用できません。 +オプティマイザは**不可視インデックス**`c1`を使用できません。 ```sql EXPLAIN SELECT c1 FROM t1 ORDER BY c1; @@ -64,7 +64,7 @@ EXPLAIN SELECT c1 FROM t1 ORDER BY c1; 3 rows in set (0.00 sec) ``` -比較すると、 `c2`**可視インデックス**であり、オプティマイザーで使用できます。 +比較すると、 `c2`**可視インデックス**であり、オプティマイザで使用できます。 ```sql EXPLAIN SELECT c2 FROM t1 ORDER BY c2; @@ -80,7 +80,7 @@ EXPLAIN SELECT c2 FROM t1 ORDER BY c2; 2 rows in set (0.00 sec) ``` -`USE INDEX` SQL ヒントを使用して強制的にインデックスを使用した場合でも、オプティマイザーは不可視インデックスを使用できません。そうでない場合は、エラーが返されます。 +`USE INDEX` SQL ヒントを使用して強制的にインデックスを使用した場合でも、オプティマイザは不可視インデックスを使用できません。そうでない場合は、エラーが返されます。 ```sql SELECT * FROM t1 USE INDEX(c1); diff --git a/sql-statements/sql-statement-select.md b/sql-statements/sql-statement-select.md index 0c14096ad61a8..bc360494a5576 100644 --- a/sql-statements/sql-statement-select.md +++ b/sql-statements/sql-statement-select.md @@ -86,7 +86,7 @@ TableSample ::= | 構文要素 | 説明 | | :--------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `TableOptimizerHints` | これは、TiDB のオプティマイザーの動作を制御するためのヒントです。詳細については、[オプティマイザのヒント](/optimizer-hints.md)を参照してください。 | +| `TableOptimizerHints` | これは、TiDB のオプティマイザの動作を制御するためのヒントです。詳細については、[オプティマイザのヒント](/optimizer-hints.md)を参照してください。 | | `ALL` 、 `DISTINCT` 、 `DISTINCTROW` | `ALL` 、 `DISTINCT` / `DISTINCTROW`修飾子は、重複する行を返すかどうかを指定します。ALL（デフォルト）を指定すると、一致するすべての行が返されます。 | | `HIGH_PRIORITY` | `HIGH_PRIORITY`は、現在のステートメントに他のステートメントよりも高い優先順位を与えます。 | | `SQL_CALC_FOUND_ROWS` | TiDBはこの機能をサポートしておらず、 [`tidb_enable_noop_functions=1`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)が設定されていない限りエラーを返します。 | diff --git a/sql-statements/sql-statement-set-variable.md b/sql-statements/sql-statement-set-variable.md index a6347a952f951..b6e3031fa234a 100644 --- a/sql-statements/sql-statement-set-variable.md +++ b/sql-statements/sql-statement-set-variable.md @@ -107,7 +107,7 @@ SELECT @myvar, @myvar + 1; - MySQLでは、 `SET GLOBAL`で行われた変更はレプリカには適用されません。しかし、TiDBでは、 `SET GLOBAL`の適用範囲は特定のシステム変数によって異なります。 - - グローバル変数: ほとんどのシステム変数 (たとえば、クラスターの動作やオプティマイザーの動作に影響するもの) の場合、 `SET GLOBAL`で行われた変更はクラスター内のすべての TiDB インスタンスに適用されます。 + - グローバル変数: ほとんどのシステム変数 (たとえば、クラスターの動作やオプティマイザの動作に影響するもの) の場合、 `SET GLOBAL`で行われた変更はクラスター内のすべての TiDB インスタンスに適用されます。 - インスタンスレベルの変数: 一部のシステム変数 (たとえば、 `max_connections` ) の場合、 `SET GLOBAL`で行われた変更は、現在の接続で使用されている TiDB インスタンスにのみ適用されます。 したがって、 `SET GLOBAL`を使用して変数を変更する場合は、常にその変数の[ドキュメント](/system-variables.md) 、特に「クラスターに保持」属性をチェックして、変更の範囲を確認してください。 diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 650f6d3be869e..285de0aa61613 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -24,7 +24,7 @@ SQLチューニングは、データベースのパフォーマンスを最適 2. 実行計画を分析します。 - - 特定されたステートメントに対してクエリ オプティマイザーによって生成された実行計画を調べます。 + - 特定されたステートメントに対してクエリ オプティマイザによって生成された実行計画を調べます。 - これらのプランが合理的に効率的であり、適切なインデックスと結合方法が使用されているかどうかを確認します。 3. 最適化を実装する: @@ -131,7 +131,7 @@ PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql - [クエリ処理を理解する](#understand-query-processing) - [クエリ処理ワークフロー](#query-processing-workflow) - - [オプティマイザーの基礎](#optimizer-fundamentals) + - [オプティマイザの基礎](#optimizer-fundamentals) - [統計管理](#statistics-management) - [実行計画を理解する](#understand-execution-plans) - [TiDBが実行計画を構築する方法](#how-tidb-builds-an-execution-plan) @@ -150,7 +150,7 @@ PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql ### クエリ処理を理解する {#understand-query-processing} -このセクションでは、クエリ処理ワークフロー、オプティマイザーの基礎、および統計管理について説明します。 +このセクションでは、クエリ処理ワークフロー、オプティマイザの基礎、および統計管理について説明します。 #### クエリ処理ワークフロー {#query-processing-workflow} @@ -158,17 +158,17 @@ PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql ![workflow](/media/sql-tuning/workflow-tiflash.png) -上の図では、プロトコルレイヤーの右側に TiDBサーバーのオプティマイザーがあり、次のように SQL ステートメントを処理します。 +上の図では、プロトコルレイヤーの右側に TiDBサーバーのオプティマイザがあり、次のように SQL ステートメントを処理します。 -1. SQL ステートメントはプロトコルレイヤーを介して SQL オプティマイザーに到達し、抽象構文ツリー (AST) に解析されます。 +1. SQL ステートメントはプロトコルレイヤーを介して SQL オプティマイザに到達し、抽象構文ツリー (AST) に解析されます。 2. TiDBは、それが[ポイントゲット](/explain-indexes.md#point_get-and-batch_point_get)文であるかどうかを識別します。この文は、 `SELECT * FROM t WHERE pk_col = 1`や`SELECT * FROM t WHERE uk_col IN (1,2,3)`などの主キーまたは一意キーを介した単純な1テーブル検索です。`Point Get`の場合、TiDBは後続の最適化手順をスキップし、SQLエグゼキュータで直接実行します。 3. クエリが`Point Get`でない場合、AST は論理変換され、TiDB は特定のルールに基づいて SQL を論理的に書き換えます。 4. 論理変換後、TiDB はコストベースの最適化を通じて AST を処理します。 -5. コストベースの最適化では、オプティマイザーは統計を使用して適切な演算子を選択し、物理的な実行計画を生成します。 +5. コストベースの最適化では、オプティマイザは統計を使用して適切な演算子を選択し、物理的な実行計画を生成します。 6. 生成された物理実行計画は、実行のために TiDB ノードの SQL 実行プログラムに送信されます。 7. 従来のシングルノードデータベースとは異なり、TiDBは、データが格納されているTiKVノードまたはTiFlashノードに演算子またはコプロセッサをプッシュダウンします。このアプローチは、データが格納されている実行計画の一部を処理するため、分散アーキテクチャを効率的に活用し、リソースを並列化し、ネットワークデータ転送を削減します。その後、TiDBノードエグゼキュータが最終結果を組み立て、クライアントに返します。 -#### オプティマイザーの基礎 {#optimizer-fundamentals} +#### オプティマイザの基礎 {#optimizer-fundamentals} TiDBはコストベースオプティマイザ（CBO）を使用して、SQL文に対して最も効率的な実行計画を決定します。オプティマイザは複数の実行戦略を評価し、推定コストが最も低いものを選択します。コストは以下のような要因に依存します。 @@ -271,7 +271,7 @@ SHOW VARIABLES LIKE 'tidb\_auto\_analyze%'; #### TiDBが実行計画を構築する方法 {#how-tidb-builds-an-execution-plan} -SQL ステートメントは、TiDB オプティマイザーで主に 3つの最適化段階を経ます。 +SQL ステートメントは、TiDB オプティマイザで主に 3つの最適化段階を経ます。 1. [前処理](#1-pre-processing) 2. [論理変換](#2-logical-transformation) @@ -305,7 +305,7 @@ EXPLAIN SELECT id, name FROM emp WHERE id = 901; TiDBオプティマイザは、統計情報を用いてSQL文の各ステップで処理される行数を推定し、各ステップにコストを割り当てます。コストベースの最適化では、オプティマイザはインデックスアクセスや結合方法など、考えられるすべてのプランを評価し、各プランの合計コストを計算します。そして、合計コストが最小となる実行計画を選択します。 -次の図は、コストベース最適化において考慮される様々なデータアクセスパスと行セット操作を示しています。データ取得パスについては、オプティマイザーはインデックススキャンとフルテーブルスキャンのどちらが最も効率的な方法であるかを判断し、行ベースのTiKVストレージと列指向のTiFlashストレージのどちらからデータを取得するかを決定します。 +次の図は、コストベース最適化において考慮される様々なデータアクセスパスと行セット操作を示しています。データ取得パスについては、オプティマイザはインデックススキャンとフルテーブルスキャンのどちらが最も効率的な方法であるかを判断し、行ベースのTiKVストレージと列指向のTiFlashストレージのどちらからデータを取得するかを決定します。 オプティマイザは、集計、結合、ソートなど、行セットを操作する操作も評価します。例えば、集計演算子では`HashAgg`または`StreamAgg`のいずれかが使用される可能性がありますが、結合方法では`HashJoin` 、 `MergeJoin` 、または`IndexJoin`のいずれかが選択されます。 @@ -504,7 +504,7 @@ LIMIT 3; 1. 重大な過小評価：最初のリーフノード`IndexReader_76`インデックス`index_orders_on_adjustment_id(adjustment_id)`からデータを読み取ります。実際の行数（ `actRows` ）は256,811,189で、推定された1行（ `estRows` ）よりも大幅に多くなっています。 2. メモリ オーバーフロー: この過小評価により、ハッシュ結合演算子`HashJoin_69`が予想よりもはるかに多くのデータを含むハッシュテーブルを構築し、過剰なメモリ(22.6 GB) とディスク領域 (7.65 GB) を消費します。 3. クエリの終了： `HashJoin_69`とその上位の演算子の`actRows`の値が`0`の場合、一致する行がないか、リソース制約によりクエリが終了したことを示します。この場合、ハッシュ結合はメモリを過剰に消費し、メモリ制御メカニズムがトリガーされてクエリが終了します。 -4. 結合順序が正しくありません: この非効率的な計画の根本的な原因は、 `IndexRangeScan_75`に対する`estRows`を大幅に過小評価していることであり、オプティマイザーが誤った結合順序を選択することになります。 +4. 結合順序が正しくありません: この非効率的な計画の根本的な原因は、 `IndexRangeScan_75`に対する`estRows`を大幅に過小評価していることであり、オプティマイザが誤った結合順序を選択することになります。 これらの問題に対処するには、特に`orders`テーブルと`index_orders_on_adjustment_id`インデックスのテーブル統計が最新であることを確認します。 @@ -669,7 +669,7 @@ WHERE クエリのパフォーマンスを向上させるには、 `source_type` 、 `target_type` 、 `amount`列を含むカバーリングインデックスを作成します。この最適化により、追加のテーブル参照が不要になり、実行時間が90ミリ秒に短縮されます。TiDBはデータスキャンのためにTiKVに1つのcopタスクを送信するだけで済みます。 -インデックスを作成したら、 `ANALYZE TABLE`ステートメントを実行して統計情報を収集します。TiDBでは、インデックスを作成しても統計は自動的に更新されないため、テーブルを分析することで、オプティマイザーが新しいインデックスを選択するようになります。 +インデックスを作成したら、 `ANALYZE TABLE`ステートメントを実行して統計情報を収集します。TiDBでは、インデックスを作成しても統計は自動的に更新されないため、テーブルを分析することで、オプティマイザが新しいインデックスを選択するようになります。 ```sql CREATE INDEX logs_covered ON logs(snapshot_id, user_id, status, source_type, target_type, amount); @@ -755,7 +755,7 @@ ANALYZE TABLE test INDEX test_new; 以下のクエリの実行には11分9秒かかります。これは、101行しか返さないクエリとしては長すぎます。パフォーマンスの低下には、いくつかの要因が考えられます。 -- 非効率的なインデックスの使用: オプティマイザーは`created_at`のインデックスを選択し、結果として 25,147,450 行がスキャンされます。 +- 非効率的なインデックスの使用: オプティマイザは`created_at`のインデックスを選択し、結果として 25,147,450 行がスキャンされます。 - 大きな中間結果セット: 日付範囲フィルターを適用した後も、12,082,311 行の処理が必要です。 - 遅延フィルタリング: テーブルにアクセスした後、最も選択的な述語`(mode, user_id, and label_id)`が適用され、結果は 16,604 行になります。 - ソートのオーバーヘッド: 16,604 行の最終ソート操作により、追加の処理時間が発生します。 @@ -850,7 +850,7 @@ TiFlash を戦略的に使用することで、クエリパフォーマンスが TPC-Hクエリ14は、テーブル`order_line`とテーブル`item`の結合を伴います。このクエリはTiKVでは**21.1秒**かかりますが、 TiFlash MPPモードではわずか**1.41秒**で実行され、15倍の速度向上が見込まれます。 - TiKVプラン：TiDBはテーブル`lineitem`から3,864,397行、テーブル`part`から1000万行を取得します。ハッシュ結合演算（ `HashJoin_21` ）と、それに続く射影演算（ `Projection_38` ）および集計演算（ `HashAgg_9` ）はTiDB内で実行されます。 -- TiFlashプラン：オプティマイザーは、`order_line`と`item`の両方のテーブルでTiFlashレプリカを検出します。TiDBはコスト見積もりに基づいて自動的にMPPモードを選択し、クエリ全体をTiFlash列指向ストレージエンジン内で実行します。これにはテーブルスキャン、ハッシュ結合、列プロジェクション、集計が含まれ、TiKVプランと比較してパフォーマンスが大幅に向上します。 +- TiFlashプラン：オプティマイザは、`order_line`と`item`の両方のテーブルでTiFlashレプリカを検出します。TiDBはコスト見積もりに基づいて自動的にMPPモードを選択し、クエリ全体をTiFlash列指向ストレージエンジン内で実行します。これにはテーブルスキャン、ハッシュ結合、列プロジェクション、集計が含まれ、TiKVプランと比較してパフォーマンスが大幅に向上します。 クエリは次のとおりです。 @@ -984,7 +984,7 @@ TiFlash上の実行計画は次のとおりです。 ##### TiKVとTiFlash間のクエリルーティング {#query-routing-between-tikv-and-tiflash} -大量のマルチテナント データを持つテーブルに対してTiFlashレプリカを有効にすると、オプティマイザーは行数に基づいてクエリを TiKV またはTiFlashのいずれかにルーティングします。 +大量のマルチテナント データを持つテーブルに対してTiFlashレプリカを有効にすると、オプティマイザは行数に基づいてクエリを TiKV またはTiFlashのいずれかにルーティングします。 - 小規模テナント: TiKV は、テーブル範囲スキャンによる小規模クエリに高い同時実行性を提供するため、データサイズが小さいテナントに適しています。 - 大規模テナント: 大規模なデータセット (この場合は 1,000 万行など) を持つテナントの場合、 TiFlash は次の利点により効率的です。 diff --git a/subquery-optimization.md b/subquery-optimization.md index 25f90f06edd8c..be646e2576793 100644 --- a/subquery-optimization.md +++ b/subquery-optimization.md @@ -90,4 +90,4 @@ explain select * from t1 where exists (select * from t2); 同様に、実行計画でインデックス結合が選択されている場合、準結合クエリは駆動テーブルとして外部クエリのみを使用できます。この場合、サブクエリの結果が外部クエリの結果よりも小さい場合、実行速度が予想よりも遅くなる可能性があります。 -`SEMI_JOIN_REWRITE()`を使用してクエリを書き換えると、オプティマイザーは選択範囲を拡張して、より適切な実行計画を選択できます。 +`SEMI_JOIN_REWRITE()`を使用してクエリを書き換えると、オプティマイザは選択範囲を拡張して、より適切な実行計画を選択できます。 diff --git a/system-variable-reference.md b/system-variable-reference.md index f444db8d98b84..f12ade7c57aeb 100644 --- a/system-variable-reference.md +++ b/system-variable-reference.md @@ -3044,7 +3044,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [最適なパフォーマンスを得るための TiDB の設定](/tidb-performance-tuning-config.md) - [制御実行計画](/control-execution-plan.md) -- [オプティマイザー修正コントロール](/optimizer-fix-controls.md) +- [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [SQL 非プリペアド実行プランキャッシュ](/sql-non-prepared-plan-cache.md) - [システム変数](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) - [TiDB 7.2.0 リリースノート](/releases/release-7.2.0.md) diff --git a/system-variables.md b/system-variables.md index 5c1eb02e9172b..c291d36755614 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1635,7 +1635,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 値のオプション： - `1` : TiDB v6.4.0 以前のバージョンでデフォルトで使用されているコストモデルバージョン 1 を有効にします。 - `2` :[コストモデル バージョン2](/cost-model.md#cost-model-version-2)を有効にします。これは TiDB v6.5.0 で一般提供されており、内部テストではバージョン 1 よりも正確です。 -- コストモデルのバージョンは、オプティマイザーの計画決定に影響します。詳細については、[コストモデル](/cost-model.md)を参照してください。 +- コストモデルのバージョンは、オプティマイザの計画決定に影響します。詳細については、[コストモデル](/cost-model.md)を参照してください。 ### tidb_current_ts @@ -2190,7 +2190,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `OFF` -- この変数は、TiDB がオプティマイザーをガイドする拡張統計を収集できるかどうかを示します。詳細については、[拡張統計入門](/extended-statistics.md)を参照してください。 +- この変数は、TiDB がオプティマイザをガイドする拡張統計を収集できるかどうかを示します。詳細については、[拡張統計入門](/extended-statistics.md)を参照してください。 ### tidb_enable_external_ts_read New in v6.4.0 @@ -4526,7 +4526,7 @@ mysql> desc select count(distinct a) from test.t; - デフォルト値: `""` - この変数は、オプティマイザの内部動作の一部を制御するために使用されます。 - オプティマイザの動作は、ユーザーシナリオやSQLステートメントによって異なる場合があります。この変数を使用することで、オプティマイザをより細かく制御でき、オプティマイザの動作変更によってアップグレード後に発生するパフォーマンス低下を防ぐことができます。 -- より詳細な概要については、[オプティマイザー修正コントロール](/optimizer-fix-controls.md)を参照してください。 +- より詳細な概要については、[オプティマイザ修正コントロール](/optimizer-fix-controls.md)を参照してください。 @@ -4539,7 +4539,7 @@ mysql> desc select count(distinct a) from test.t; - デフォルト値: `""` - この変数は、オプティマイザの内部動作の一部を制御するために使用されます。 - オプティマイザの動作は、ユーザーシナリオやSQLステートメントによって異なる場合があります。この変数を使用することで、オプティマイザをより細かく制御でき、オプティマイザの動作変更によってアップグレード後に発生するパフォーマンス低下を防ぐことができます。 -- より詳細な概要については、[オプティマイザー修正コントロール](/optimizer-fix-controls.md)を参照してください。 +- より詳細な概要については、[オプティマイザ修正コントロール](/optimizer-fix-controls.md)を参照してください。 diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index 37a399674ef43..1670e6b848005 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -478,7 +478,7 @@ summary: 2022年のTiDB Cloudのリリースノートについて説明します - 列指向ストレージ[TiFlash](/tiflash/tiflash-overview.md)が一般提供 (GA) になりました。 - TiFlashにより、TiDBは本質的にハイブリッドトランザクション／分析処理（HTAP）データベースとなります。アプリケーションデータはまずTiKVに保存され、その後Raftコンセンサスアルゴリズムを介してTiFlashに複製されます。つまり、行ストレージから列ストレージへのリアルタイムレプリケーションが実現されます。 - - TiFlashレプリカを持つテーブルの場合、TiDB オプティマイザーはコスト見積もりに基づいて TiKV レプリカとTiFlashレプリカのどちらを使用するかを自動的に決定します。 + - TiFlashレプリカを持つテーブルの場合、TiDB オプティマイザはコスト見積もりに基づいて TiKV レプリカとTiFlashレプリカのどちらを使用するかを自動的に決定します。 TiFlashがもたらすメリットを体験するには、 [TiDB Cloud HTAP クイックスタートガイド](/tidb-cloud/tidb-cloud-htap-quickstart.md)ご覧ください。 diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index 748f8942ef4ee..c485192ff292e 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -57,7 +57,7 @@ TiDB Cloud Starterの列指向ストレージは、行ベースストレージ 列指向ストレージは、トランザクション ワークロードと分析ワークロードをシームレスに融合することで、TiDB のハイブリッドトランザクションおよび分析処理 (HTAP) 機能を有効にする重要な機能です。 -列指向ストレージデータを効率的に管理するために、 TiDB Cloud Starterは独立したElastic TiFlashエンジンを使用します。クエリ実行中、オプティマイザーはクラスターに対し、行ベースストレージと列指向ストレージのどちらからデータを取得するかを自動的に決定するよう指示します。 +列指向ストレージデータを効率的に管理するために、 TiDB Cloud Starterは独立したElastic TiFlashエンジンを使用します。クエリ実行中、オプティマイザはクラスターに対し、行ベースストレージと列指向ストレージのどちらからデータを取得するかを自動的に決定するよう指示します。 ### TiDB Cloud Starter で列指向ストレージを使用するのはいつですか? {#when-should-i-use-columnar-storage-in-tidb-cloud-starter} diff --git a/tidb-cloud/tidb-cloud-htap-quickstart.md b/tidb-cloud/tidb-cloud-htap-quickstart.md index 182caf1ce5c0a..ab5f0bc08a0da 100644 --- a/tidb-cloud/tidb-cloud-htap-quickstart.md +++ b/tidb-cloud/tidb-cloud-htap-quickstart.md @@ -121,7 +121,7 @@ ORDER BY LIMIT 20; ``` - TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいて、TiKVレプリカとTiFlashレプリカのどちらを使用するかを自動的に決定します。前述の`EXPLAIN ANALYZE`の文では、 `/*+ READ_FROM_STORAGE(TIKV[games]) */`ヒントを使用してオプティマイザーにTiKVを選択させ、TiKVの実行統計を確認できるようにしています。 + TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザはコスト見積もりに基づいて、TiKVレプリカとTiFlashレプリカのどちらを使用するかを自動的に決定します。前述の`EXPLAIN ANALYZE`の文では、 `/*+ READ_FROM_STORAGE(TIKV[games]) */`ヒントを使用してオプティマイザにTiKVを選択させ、TiKVの実行統計を確認できるようにしています。 > **Note:** > @@ -196,7 +196,7 @@ ORDER BY > **Note:** > -> サンプルデータセットは小さく、このドキュメントのクエリは比較的単純であるため、このクエリに対してオプティマイザーにTiKVを選択させてから同じクエリを再度実行すると、TiKV はキャッシュを再利用するため、クエリは大幅に高速になります。データが頻繁に更新される場合、キャッシュは無効になります。 +> サンプルデータセットは小さく、このドキュメントのクエリは比較的単純であるため、このクエリに対してオプティマイザにTiKVを選択させてから同じクエリを再度実行すると、TiKV はキャッシュを再利用するため、クエリは大幅に高速になります。データが頻繁に更新される場合、キャッシュは無効になります。 ## もっと詳しく知る {#learn-more} diff --git a/tidb-cloud/tidb-cloud-sql-tuning-overview.md b/tidb-cloud/tidb-cloud-sql-tuning-overview.md index d4f5e87ad4054..9afee177e0210 100644 --- a/tidb-cloud/tidb-cloud-sql-tuning-overview.md +++ b/tidb-cloud/tidb-cloud-sql-tuning-overview.md @@ -16,7 +16,7 @@ SQL文のパフォーマンスを向上させるには、以下の原則を考 - スキャン対象データの範囲を最小限に抑えましょう。常に、必要最小限のデータのみをスキャンし、すべてのデータをスキャンすることは避けるのが最善策です。 - 適切なインデックスを使用してください。SQL文の`WHERE`句の各列には、対応するインデックスが存在することを確認してください。そうでない場合、 `WHERE`句はテーブル全体をスキャンするため、パフォーマンスが低下します。 -- 適切な結合タイプを使用してください。クエリ内の各テーブルのサイズと相関関係に応じて、適切な結合タイプを選択することが非常に重要です。一般に、TiDB のコストベースのオプティマイザーは、最適な結合タイプを自動的に選択します。ただし、場合によっては、結合タイプを手動で指定する必要がある場合があります。詳細については、[テーブル結合を使用するステートメントについて説明します](/explain-joins.md)を参照してください。 +- 適切な結合タイプを使用してください。クエリ内の各テーブルのサイズと相関関係に応じて、適切な結合タイプを選択することが非常に重要です。一般に、TiDB のコストベースのオプティマイザは、最適な結合タイプを自動的に選択します。ただし、場合によっては、結合タイプを手動で指定する必要がある場合があります。詳細については、[テーブル結合を使用するステートメントについて説明します](/explain-joins.md)を参照してください。 - 適切なストレージエンジンを使用してください。ハイブリッドトランザクションおよび分析処理（HTAP）ワークロードには、 TiFlashストレージエンジンを使用することをお勧めします。[HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md)を参照してください。 TiDB Cloudには、スロークエリを分析するのに役立つツールがいくつか用意されています。以下のセクションでは、スロークエリを最適化するためのいくつかの方法について説明します。 diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index 60b18a8616279..530ad43570577 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -66,7 +66,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error ``` -4. TiDB オプティマイザーが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 +4. TiDB オプティマイザが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 ```sql ANALYZE TABLE customer; diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index 948f3bf243c85..fa5211f4a314e 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -67,7 +67,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error ``` -4. TiDB オプティマイザーが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 +4. TiDB オプティマイザが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 ```sql ANALYZE TABLE customer; diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index c62048c2aa271..3762632bcfcd2 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -67,7 +67,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error ``` -4. TiDB オプティマイザーが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 +4. TiDB オプティマイザが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 ```sql ANALYZE TABLE customer; diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index 3520605487a01..bc5fb92dc8636 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -78,7 +78,7 @@ raft-engine.prefill-for-recycle = true go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error ``` -4. TiDB オプティマイザーが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 +4. TiDB オプティマイザが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 ```sql ANALYZE TABLE customer; diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index f9cc6b64cec59..fd579d1452477 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -78,7 +78,7 @@ raft-engine.prefill-for-recycle = true go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error ``` -4. TiDB オプティマイザーが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 +4. TiDB オプティマイザが最適な実行計画を生成できるようにするには、TPC-C テストを実行する前に次の SQL ステートメントを実行して統計を収集します。 ```sql ANALYZE TABLE customer; diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 207cac83fcd9d..5f060a35c1a3f 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -27,7 +27,7 @@ TiDBのパフォーマンスを最適化するには、さまざまな設定を TiDBのパフォーマンスを最適化するために、一般的に以下の設定が使用されます。 - [SQLプリペアドプランキャッシュ](/sql-prepared-plan-cache.md)などの実行プランキャッシュ[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)強化します[インスタンスレベルの実行プランキャッシュ](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) -- [オプティマイザー修正コントロール](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 +- [オプティマイザ修正コントロール](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 - ストレージエンジン[Titan](/storage-engine/titan-overview.md)をより積極的に活用する。 - 書き込み負荷の高いワークロード下でも最適かつ安定したパフォーマンスを確保するために、TiKVの圧縮およびフロー制御の設定を微調整します。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index 9965696a76fc3..2d767da4b6816 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -45,8 +45,8 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ - リクエストのタイプが`run_mpp_task` 、 `dispatch_mpp_task` 、または`mpp_establish_conn`の場合、SQL文の実行がTiFlashに部分的または完全にプッシュダウンされたことを示します。これには通常、結合操作とデータ分散操作が含まれます。これはTiFlashで最も一般的なリクエストタイプです。 - リクエストのタイプが`cop`の場合、そのリクエストに関連するステートメントがTiFlashに完全にプッシュダウンされていないことを示します。通常、TiDB はデータアクセスとフィルタリングのために、テーブルフルスキャン演算子をTiFlashにプッシュダウンします。積み上げチャートで`cop`が最も多く表示されるリクエストタイプになった場合は、それが妥当かどうかを確認する必要があります。 - - SQL ステートメントによってクエリされるデータの量が大きい場合、オプティマイザーはコストモデルに従って、 TiFlash のフルテーブルスキャンの方がコスト効率が高いと見積もる場合があります。 - - クエリ対象のテーブルのスキーマに適切なインデックスがない場合、クエリ対象のデータ量が少ない場合でも、オプティマイザーはクエリをTiFlashにプッシュダウンしてテーブル全体をスキャンするしかありません。このような場合、適切なインデックスを作成し、TiKVを介してデータにアクセスする方が効率的です。 + - SQL ステートメントによってクエリされるデータの量が大きい場合、オプティマイザはコストモデルに従って、 TiFlash のフルテーブルスキャンの方がコスト効率が高いと見積もる場合があります。 + - クエリ対象のテーブルのスキーマに適切なインデックスがない場合、クエリ対象のデータ量が少ない場合でも、オプティマイザはクエリをTiFlashにプッシュダウンしてテーブル全体をスキャンするしかありません。このような場合、適切なインデックスを作成し、TiKVを介してデータにアクセスする方が効率的です。 - 要求期間: すべてのTiFlashインスタンス内の各 MPP およびコプロセッサ要求タイプの合計処理期間。これには平均レイテンシーと p99レイテンシーが含まれます。 diff --git a/tiflash/tiflash-late-materialization.md b/tiflash/tiflash-late-materialization.md index f962ff7286209..6da66cfb8e3a2 100644 --- a/tiflash/tiflash-late-materialization.md +++ b/tiflash/tiflash-late-materialization.md @@ -14,7 +14,7 @@ TiFlash の遅延マテリアライゼーションは、OLAP シナリオにお - 無効にすると、フィルタ条件（ `WHERE`句）を含む`SELECT`ステートメントを処理するために、 TiFlash はクエリに必要な列からすべてのデータを読み取り、クエリ条件に基づいてデータをフィルタリングして集計します。 - 有効にすると、 TiFlash はフィルター条件の一部を TableScan オペレーターにプッシュダウンすることをサポートします。つまり、 TiFlash はまず TableScan オペレーターにプッシュダウンされたフィルター条件に関連する列データをスキャンし、条件を満たす行をフィルタリングした後、それらの行の残りの列データをスキャンしてさらに計算を行います。これにより、データ処理における IO スキャンと計算量が削減されます。 -OLAPシナリオにおける特定のクエリのパフォーマンスを向上させるため、v7.1.0以降ではTiFlashの遅延マテリアライゼーション機能がデフォルトで有効化されています。TiDBオプティマイザーは、統計情報とフィルタ条件に基づいてプッシュダウンするフィルタ条件を決定し、フィルタリング率の高いフィルタ条件を優先的にプッシュダウンします。詳細なアルゴリズムについては、 [RFC文書](https://github.com/pingcap/tidb/tree/release-8.5/docs/design/2022-12-06-support-late-materialization.md)を参照してください。 +OLAPシナリオにおける特定のクエリのパフォーマンスを向上させるため、v7.1.0以降ではTiFlashの遅延マテリアライゼーション機能がデフォルトで有効化されています。TiDBオプティマイザは、統計情報とフィルタ条件に基づいてプッシュダウンするフィルタ条件を決定し、フィルタリング率の高いフィルタ条件を優先的にプッシュダウンします。詳細なアルゴリズムについては、 [RFC文書](https://github.com/pingcap/tidb/tree/release-8.5/docs/design/2022-12-06-support-late-materialization.md)を参照してください。 例えば： diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index 1d4dd2ce989cb..6a85725d7f3e9 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -69,7 +69,7 @@ TiFlash が読み取り要求を受信するたびに、リージョンレプリ TiDB は、 TiFlash (列単位) または TiKV (行単位) の使用を自動的に選択するか、または 1つのクエリで両方を使用して、最高のパフォーマンスを確保できます。 -この選択メカニズムは、クエリ実行時に異なるインデックスを選択するTiDBのメカニズムに似ています。TiDBオプティマイザーは、読み取りコストの統計に基づいて適切な選択を行います。 +この選択メカニズムは、クエリ実行時に異なるインデックスを選択するTiDBのメカニズムに似ています。TiDBオプティマイザは、読み取りコストの統計に基づいて適切な選択を行います。 ### コンピューティングの加速 {#computing-acceleration} diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index 764393bb511a1..2addb3a125006 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -25,7 +25,7 @@ summary: マシン リソースを計画し、TiDB パラメータを調整す ### MPPモードを強制的に有効にする {#forcibly-enable-the-mpp-mode} -MPP実行計画は分散コンピューティングリソースを最大限に活用できるため、バッチデータクエリの効率を大幅に向上させます。オプティマイザーがクエリに対してMPP実行計画を生成しない場合は、MPPモードを強制的に有効にすることができます。 +MPP実行計画は分散コンピューティングリソースを最大限に活用できるため、バッチデータクエリの効率を大幅に向上させます。オプティマイザがクエリに対してMPP実行計画を生成しない場合は、MPPモードを強制的に有効にすることができます。 変数[`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)は、オプティマイザのコスト見積もりを無視し、クエリ実行時にTiFlashのMPPモードを強制的に使用するかどうかを制御します。MPPモードを強制的に有効にするには、次のコマンドを実行します。 diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index f86bd1ccf1497..490b1ec2accca 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -11,7 +11,7 @@ TiDBは、 TiFlashレプリカを読み取る3つの方法を提供します。 ## スマートな選択 {#smart-selection} -TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。`desc`または`explain analyze`ステートメントを使用して、 TiFlashレプリカが選択されているかどうかを確認できます。例： +TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。`desc`または`explain analyze`ステートメントを使用して、 TiFlashレプリカが選択されているかどうかを確認できます。例： ```sql desc select count(*) from test.t; @@ -77,7 +77,7 @@ explain analyze select count(*) from test.t; SESSION レベルのデフォルト構成は、TiDB INSTANCE レベルの構成を継承します。 -最終的なエンジン構成はセッションレベルの構成です。つまり、セッションレベルの構成はインスタンスレベルの構成をオーバーライドします。例えば、インスタンスレベルで「tikv」を設定し、セッションレベルで「tiflash」を設定した場合、 TiFlashレプリカが読み込まれます。最終的なエンジン構成が「tikv」と「tiflash」の場合、TiKVレプリカとTiFlashレプリカの両方が読み込まれ、オプティマイザーはより適切なエンジンを自動的に選択して実行します。 +最終的なエンジン構成はセッションレベルの構成です。つまり、セッションレベルの構成はインスタンスレベルの構成をオーバーライドします。例えば、インスタンスレベルで「tikv」を設定し、セッションレベルで「tiflash」を設定した場合、 TiFlashレプリカが読み込まれます。最終的なエンジン構成が「tikv」と「tiflash」の場合、TiKVレプリカとTiFlashレプリカの両方が読み込まれ、オプティマイザはより適切なエンジンを自動的に選択して実行します。 > **Note:** > diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index ab668fc94171d..f1391d1df9bbf 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -31,7 +31,7 @@ TiFlashは、クエリ実行にMPPモードをサポートしています。こ | | tidb_allow_mpp=オフ | tidb_allow_mpp=on (デフォルト) | | --------------------------- | ----------------- | ----------------------------------------- | -| tidb_enforce_mpp=off（デフォルト） | MPP モードは使用されません。 | オプティマイザーはコスト推定に基づいて MPP モードを選択します。(デフォルト) | +| tidb_enforce_mpp=off（デフォルト） | MPP モードは使用されません。 | オプティマイザはコスト推定に基づいて MPP モードを選択します。(デフォルト) | | tidb_enforce_mpp=オン | MPP モードは使用されません。 | TiDB はコスト見積りを無視し、MPP モードを選択します。 | たとえば、MPP モードを使用しない場合は、次のステートメントを実行できます。 @@ -40,7 +40,7 @@ TiFlashは、クエリ実行にMPPモードをサポートしています。こ set @@session.tidb_allow_mpp=0; ``` -TiDB のコストベース オプティマイザーで MPP モード (デフォルト) を使用するかどうかを自動的に決定する場合は、次のステートメントを実行します。 +TiDB のコストベース オプティマイザで MPP モード (デフォルト) を使用するかどうかを自動的に決定する場合は、次のステートメントを実行します。 ```sql set @@session.tidb_allow_mpp=1; @@ -83,7 +83,7 @@ set @@session.tidb_enforce_mpp=1; ## MPPモードのアルゴリズムサポート {#algorithm-support-for-the-mpp-mode} -MPPモードは、ブロードキャストハッシュ結合、シャッフルハッシュ結合、シャッフルハッシュ集計、Union All、TopN、およびLimitという物理アルゴリズムをサポートしています。オプティマイザーは、クエリで使用するアルゴリズムを自動的に決定します。具体的なクエリ実行計画を確認するには、 `EXPLAIN`のステートメントを実行してください。`EXPLAIN`のステートメントの結果にExchangeSender演算子とExchangeReceiver演算子が表示された場合、MPPモードが有効になっていることを示します。 +MPPモードは、ブロードキャストハッシュ結合、シャッフルハッシュ結合、シャッフルハッシュ集計、Union All、TopN、およびLimitという物理アルゴリズムをサポートしています。オプティマイザは、クエリで使用するアルゴリズムを自動的に決定します。具体的なクエリ実行計画を確認するには、 `EXPLAIN`のステートメントを実行してください。`EXPLAIN`のステートメントの結果にExchangeSender演算子とExchangeReceiver演算子が表示された場合、MPPモードが有効になっていることを示します。 次のステートメントは、TPC-H テスト セット内のテーブル構造を例として示しています。 diff --git a/tiup/tiup-bench.md b/tiup/tiup-bench.md index f88d046cc3c66..544d93ab6d750 100644 --- a/tiup/tiup-bench.md +++ b/tiup/tiup-bench.md @@ -140,7 +140,7 @@ Flags: 2. 統計を収集します。 - OLAPシナリオでは、TiDBオプティマイザーが最適な実行計画を生成できるように、以下のSQL文を実行して事前に統計情報を収集してください。**`tidb_analyze_column_options` `ALL`に設定してください。そうしないと、統計情報を収集するとクエリのパフォーマンスが大幅に低下する可能性があります。** + OLAPシナリオでは、TiDBオプティマイザが最適な実行計画を生成できるように、以下のSQL文を実行して事前に統計情報を収集してください。**`tidb_analyze_column_options` `ALL`に設定してください。そうしないと、統計情報を収集するとクエリのパフォーマンスが大幅に低下する可能性があります。** ```sql set global tidb_analyze_column_options='ALL'; diff --git a/wrong-index-solution.md b/wrong-index-solution.md index 146f87d507971..850ecc3a61273 100644 --- a/wrong-index-solution.md +++ b/wrong-index-solution.md @@ -5,14 +5,14 @@ summary: 間違ったインデックスの問題を解決する方法を学び # インデックス問題の解決方法 {#wrong-index-solution} -一部のクエリの実行速度が期待値に達しない場合は、オプティマイザーがクエリを実行するために間違ったインデックスを選択する可能性があります。 +一部のクエリの実行速度が期待値に達しない場合は、オプティマイザがクエリを実行するために間違ったインデックスを選択する可能性があります。 -オプティマイザーが予期しないインデックスを選択する理由は複数あります。 +オプティマイザが予期しないインデックスを選択する理由は複数あります。 -- **古い統計**：オプティマイザーはクエリコストを推定するために統計を使用します。統計が古い場合、オプティマイザーは最適ではない選択を行う可能性があります。 +- **古い統計**：オプティマイザはクエリコストを推定するために統計を使用します。統計が古い場合、オプティマイザは最適ではない選択を行う可能性があります。 - **統計の不一致**: 統計が最新であっても、データの分布を正確に反映していない可能性があり、コストの見積もりが不正確になる可能性があります。 -- **コスト計算が正しくありません**: クエリ構造やデータ分散が複雑なため、オプティマイザーがインデックスの使用コストを誤って計算する場合があります。 -- **不適切なエンジンの選択**: 場合によっては、オプティマイザーがクエリに最適ではないストレージエンジンを選択することがあります。 +- **コスト計算が正しくありません**: クエリ構造やデータ分散が複雑なため、オプティマイザがインデックスの使用コストを誤って計算する場合があります。 +- **不適切なエンジンの選択**: 場合によっては、オプティマイザがクエリに最適ではないストレージエンジンを選択することがあります。 - **関数のプッシュダウンの制限**: 特定の関数または操作がストレージエンジンにプッシュダウンされない可能性があり、クエリのパフォーマンスに影響する可能性があります。 ## 統計の健康 {#statistics-health} @@ -21,7 +21,7 @@ summary: 間違ったインデックスの問題を解決する方法を学び ### 健康状態が低い {#low-health-state} -ヘルス状態が低いということは、TiDBが`ANALYZE`ステートメントを長期間実行していないことを意味します。`ANALYZE`コマンドを実行することで統計情報を更新できます。更新後もオプティマイザーが誤ったインデックスを使用している場合は、次のセクションを参照してください。 +ヘルス状態が低いということは、TiDBが`ANALYZE`ステートメントを長期間実行していないことを意味します。`ANALYZE`コマンドを実行することで統計情報を更新できます。更新後もオプティマイザが誤ったインデックスを使用している場合は、次のセクションを参照してください。 ### ほぼ100%の健康状態 {#near-100-health-state} @@ -63,5 +63,5 @@ summary: 間違ったインデックスの問題を解決する方法を学び - [統計](/statistics.md) - [インデックスの選択](/choose-index.md) -- [オプティマイザーヒント](/optimizer-hints.md) +- [オプティマイザヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) From 483b9750d217ca52db26937f7c9f8befce048bd3 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 14:47:29 +0900 Subject: [PATCH 2/5] i18n(ja): keep "Optimizer Fix Control(s)" feature name in English MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Optimizer Fix Controls (and the per-item "fix control") is a specific TiDB feature/mechanism name, not a descriptive phrase, so it should stay literal rather than be translated as オプティマイザ修正制御/ オプティマイザ修正コントロール. Also fixes a stray dangling text fragment in release-7.2.0.md and unifies 派生範囲/行式 in multi-column-index-best-practices.md to match the file's own established 導出 terminology and natural JA phrasing. --- TOC-tidb-cloud-essential.md | 2 +- TOC-tidb-cloud-premium.md | 2 +- TOC-tidb-cloud-starter.md | 2 +- TOC-tidb-cloud.md | 2 +- TOC.md | 2 +- .../multi-column-index-best-practices.md | 6 +++--- control-execution-plan.md | 2 +- explain-index-merge.md | 2 +- optimizer-fix-controls.md | 14 +++++++------- releases/release-6.5.7.md | 2 +- releases/release-7.2.0.md | 8 ++++---- releases/release-7.5.7.md | 2 +- releases/release-8.1.0.md | 2 +- releases/release-8.4.0.md | 2 +- system-variable-reference.md | 2 +- system-variables.md | 4 ++-- tidb-performance-tuning-config.md | 2 +- 17 files changed, 29 insertions(+), 29 deletions(-) diff --git a/TOC-tidb-cloud-essential.md b/TOC-tidb-cloud-essential.md index 55fe8332881e0..a45e019c12895 100644 --- a/TOC-tidb-cloud-essential.md +++ b/TOC-tidb-cloud-essential.md @@ -112,7 +112,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) + - [Optimizer Fix Controls](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） diff --git a/TOC-tidb-cloud-premium.md b/TOC-tidb-cloud-premium.md index 307dadfa4d2fd..639cf07ece373 100644 --- a/TOC-tidb-cloud-premium.md +++ b/TOC-tidb-cloud-premium.md @@ -110,7 +110,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) + - [Optimizer Fix Controls](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) diff --git a/TOC-tidb-cloud-starter.md b/TOC-tidb-cloud-starter.md index 329ea48b00a4f..50f81f780b788 100644 --- a/TOC-tidb-cloud-starter.md +++ b/TOC-tidb-cloud-starter.md @@ -106,7 +106,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) + - [Optimizer Fix Controls](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） diff --git a/TOC-tidb-cloud.md b/TOC-tidb-cloud.md index 25029852f8109..4df3b36432148 100644 --- a/TOC-tidb-cloud.md +++ b/TOC-tidb-cloud.md @@ -125,7 +125,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) + - [Optimizer Fix Controls](/optimizer-fix-controls.md) - [インデックスアドバイザー](/index-advisor.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) diff --git a/TOC.md b/TOC.md index e146affb1e844..81ba65dc37046 100644 --- a/TOC.md +++ b/TOC.md @@ -296,7 +296,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) + - [Optimizer Fix Controls](/optimizer-fix-controls.md) - [インデックスアドバイザー](/index-advisor.md) - チュートリアル - [1つのリージョンに複数の可用性ゾーンを展開](/multi-data-centers-in-one-city-deployment.md) diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 27c61bb270f4d..2580dc783bd3d 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -17,7 +17,7 @@ aliases: ['/ja/tidb/stable/multi-column-index-best-practices/'] ## 前提条件 {#prerequisites} - マルチ列インデックス機能は、TiDB v8.3 以降のバージョンで使用できます。 -- この機能を使用する前に、 [オプティマイザ修正制御**54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 +- この機能を使用する前に、 [optimizer fix control **54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 ## 背景: 複数列インデックス {#background-multi-column-indexes} @@ -238,7 +238,7 @@ CREATE TABLE t1 ( ### 例2: クエリプラン {#example-2-query-plan} -次のクエリプランは、派生した範囲を示しています。 +次のクエリプランは、導出された範囲を示しています。 ```sql -- Query 5: Conjunctive conditions on (a1, b1) @@ -259,7 +259,7 @@ EXPLAIN FORMAT = "brief" この例では、テーブルには約5億行あります。しかし、この最適化により、TiDBはアクセスを約4,000行、つまり全データのわずか0.0008%に絞り込むことができます。この改良により、クエリのレイテンシーは、最適化を行わない場合の2分以上から数ミリ秒へと大幅に短縮されます。 -このような条件で完全なテーブルスキャンを必要とする MySQL とは異なり、TiDB オプティマイザはこれらの派生範囲を活用して複雑な行式を効率的に処理できます。 +このような条件で完全なテーブルスキャンを必要とする MySQL とは異なり、TiDB オプティマイザはこれらの導出された範囲を活用して複雑な行の式を効率的に処理できます。 ## 結論 {#conclusion} diff --git a/control-execution-plan.md b/control-execution-plan.md index 56986bbdd97f3..9f65a232d42c7 100644 --- a/control-execution-plan.md +++ b/control-execution-plan.md @@ -11,4 +11,4 @@ SQLチューニングの最初の2章では、TiDBの実行計画の理解方法 - しかし、ヒントはSQL文を侵襲的に変更します。場合によっては、ヒントを単純に挿入することはできません。SQL [SQLプラン管理](/sql-plan-management.md)では、TiDBが別の構文を使用して実行計画の生成を非侵襲的に制御する方法と、バックグラウンドで実行計画を自動的に進化させる方法について説明しています。この方法は、バージョンアップグレードやクラスタのパフォーマンス低下によって引き起こされる実行計画の不安定性などの問題に対処するのに役立ちます。 - 最後に、[最適化ルールと式のプッシュダウンのブロックリスト](/blocklist-control-plan.md)でブロックリストの使用方法を学びます。 -上記の方法に加えて、実行計画はいくつかのシステム変数にも影響されます。システムレベルまたはセッションレベルでこれらの変数を変更することで、実行計画の生成を制御できます。v6.5.3およびv7.1.0以降、TiDBは比較的特殊な変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)を導入しました。この変数は複数の制御項目を受け入れることができ、クラスタのアップグレード後にオプティマイザの動作変更によって発生するパフォーマンスの低下を防ぐために、オプティマイザの動作をよりきめ細かく制御できます。詳細については[オプティマイザ修正コントロール](/optimizer-fix-controls.md)を参照してください。 +上記の方法に加えて、実行計画はいくつかのシステム変数にも影響されます。システムレベルまたはセッションレベルでこれらの変数を変更することで、実行計画の生成を制御できます。v6.5.3およびv7.1.0以降、TiDBは比較的特殊な変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)を導入しました。この変数は複数の制御項目を受け入れることができ、クラスタのアップグレード後にオプティマイザの動作変更によって発生するパフォーマンスの低下を防ぐために、オプティマイザの動作をよりきめ細かく制御できます。詳細については[Optimizer Fix Controls](/optimizer-fix-controls.md)を参照してください。 diff --git a/explain-index-merge.md b/explain-index-merge.md index 4f2cdc1ec962d..04a52a5e0805f 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -92,7 +92,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t, idx_a, idx_b, idx_c) */ * FROM t WHERE a > > > - SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用すると、 `tidb_enable_index_merge`設定に関係なく、オプティマイザにインデックスマージを強制的に適用させることができます。フィルタリング条件にプッシュダウンできない式が含まれている場合にインデックスマージを有効にするには、SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用する必要があります。 > -> - [オプティマイザ修正制御 52869](/optimizer-fix-controls.md#52869-new-in-v810)が`OFF`に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式（フルテーブルスキャン以外）を選択できるとき、オプティマイザはインデックスマージを自動的には選択しません。インデックスマージを使用するには、オプティマイザヒントを指定する必要があります。v8.5.7以降、この制御のデフォルト値は`ON`に変更されており、これにより前述の制限がデフォルトで解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できるようになります。 +> - [Optimizer Fix Control 52869](/optimizer-fix-controls.md#52869-new-in-v810)が`OFF`に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式（フルテーブルスキャン以外）を選択できるとき、オプティマイザはインデックスマージを自動的には選択しません。インデックスマージを使用するには、オプティマイザヒントを指定する必要があります。v8.5.7以降、この制御のデフォルト値は`ON`に変更されており、これにより前述の制限がデフォルトで解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できるようになります。 > > - 現時点では、インデックスマージは[一時テーブル](/temporary-tables.md)ではサポートされていません。 > diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index 5f573f44c60e3..098d983c81248 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -1,16 +1,16 @@ --- title: Optimizer Fix Controls -summary: オプティマイザ修正制御機能について学習し、tidb_opt_fix_control` を使用して TiDB オプティマイザをより細かく制御する方法について説明します。 +summary: Optimizer Fix Controls機能について学習し、`tidb_opt_fix_control` を使用して TiDB オプティマイザをより細かく制御する方法について説明します。 --- -# オプティマイザ修正コントロール {#optimizer-fix-controls} +# Optimizer Fix Controls {#optimizer-fix-controls} 製品が継続的に進化するにつれて、TiDBオプティマイザの動作が変化し、より合理的な実行計画が生成されます。しかし、特定のシナリオでは、新しい動作が予期しない結果につながる可能性があります。例えば、 - 一部の動作の効果は特定のシナリオに依存します。ほとんどのシナリオで改善をもたらす変更が、他のシナリオでは後退を引き起こす可能性があります。 - 場合によっては、行動の詳細の変化とその結果の関係が非常に複雑になることがあります。特定の行動の改善が、全体的な退行を引き起こす可能性があります。 -そのため、TiDBは、複数の修正項目に値を設定することで、TiDBオプティマイザの動作をきめ細かく制御できるオプティマイザ修正制御機能を提供しています。このドキュメントでは、オプティマイザ修正制御機能とその使用方法について説明し、TiDBが現在オプティマイザ修正制御でサポートしているすべての修正項目を一覧表示します。 +そのため、TiDBは、複数の修正項目に値を設定することで、TiDBオプティマイザの動作をきめ細かく制御できるOptimizer Fix Controls機能を提供しています。このドキュメントでは、Optimizer Fix Controls機能とその使用方法について説明し、TiDBが現在Optimizer Fix Controlsでサポートしているすべての修正項目を一覧表示します。 ## `tidb_opt_fix_control`の紹介 {#introduction-to-tidb-opt-fix-control} @@ -24,7 +24,7 @@ v6.5.3 および v7.1.0 以降、TiDB は、オプティマイザの動作をよ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; ``` -## オプティマイザ修正コントロールリファレンス {#optimizer-fix-controls-reference} +## Optimizer Fix Controls リファレンス {#optimizer-fix-controls-reference} ### `33031`バージョン8.0.0の新機能 {#33031-new-in-v800} @@ -105,15 +105,15 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `ON`。v8.5.7 より前では、デフォルト値は `OFF` です。 - 可能`OFF`値: `ON` -- この修正制御が `OFF` に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できるとき、オプティマイザはインデックスマージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 -- この修正制御が `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 +- このfix controlが `OFF` に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できるとき、オプティマイザはインデックスマージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 +- このfix controlが `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 ### `54337`バージョン8.3.0の新機能 {#54337-new-in-v830} - デフォルト値: `OFF` - 可能`OFF`値: `ON` - 現在、TiDBオプティマイザは、各接続詞が範囲のリストで構成される複雑な接続詞条件のインデックス範囲の導出に制限があります。これは、一般的な範囲交差を適用することで解決できます。 -- この修正コントロールを有効にすると、この制限が解除され、オプティマイザは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 +- このfix controlを有効にすると、この制限が解除され、オプティマイザは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 ### `56318` {#56318} diff --git a/releases/release-6.5.7.md b/releases/release-6.5.7.md index 8f27063a6391e..55ea21808f578 100644 --- a/releases/release-6.5.7.md +++ b/releases/release-6.5.7.md @@ -21,7 +21,7 @@ TiDB バージョン: 6.5.7 - TiDB - パーティションテーブル[＃47071](https://github.com/pingcap/tidb/issues/47071) での`ANALYZE`操作のメモリ使用量とパフォーマンスを最適化します [＃46804](https://github.com/pingcap/tidb/issues/46804) @[hawkingrei](https://github.com/hawkingrei) [＃47104](https://github.com/pingcap/tidb/issues/47104) - - プランキャッシュをサポートして、オプティマイザ修正コントロールを使用して物理的な最適化中に生成された`PointGet`演算子を含む実行計画をキャッシュします。 [＃44830](https://github.com/pingcap/tidb/issues/44830) @[qw4990](https://github.com/qw4990) + - プランキャッシュをサポートして、Optimizer Fix Controlsを使用して物理的な最適化中に生成された`PointGet`演算子を含む実行計画をキャッシュします。 [＃44830](https://github.com/pingcap/tidb/issues/44830) @[qw4990](https://github.com/qw4990) - 特定のシナリオで`OUTER JOIN`を`INNER JOIN`に変換する能力を強化する[＃49616](https://github.com/pingcap/tidb/issues/49616) @[qw4990](https://github.com/qw4990) - TiFlash diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index a5d024d8f52c9..23f17bbee5ce8 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -75,13 +75,13 @@ TiDB バージョン: 7.2.0 詳細については、[ドキュメント](/sql-plan-management.md)を参照してください。 -- オプティマイザ修正制御メカニズムを導入して、オプティマイザの動作をきめ細かく制御できるようにします [#43169](https://github.com/pingcap/tidb/issues/43169) @[time-and-fate](https://github.com/time-and-fate) +- Optimizer Fix Controlsメカニズムを導入して、オプティマイザの動作をきめ細かく制御できるようにします [#43169](https://github.com/pingcap/tidb/issues/43169) @[time-and-fate](https://github.com/time-and-fate) - より適切な実行計画を生成するため、TiDB オプティマイザの動作は製品のバージョンアップごとに進化しています。しかし、特定のシナリオでは、変更によってパフォーマンスが低下する場合があります。TiDB v7.2.0 では、オプティマイザの細かい動作を制御できるオプティマイザ修正コントロールが導入されました。これにより、一部の新しい変更をロールバックしたり、制御したりすることが可能になります。 + より適切な実行計画を生成するため、TiDB オプティマイザの動作は製品のバージョンアップごとに進化しています。しかし、特定のシナリオでは、変更によってパフォーマンスが低下する場合があります。TiDB v7.2.0 では、オプティマイザの細かい動作を制御できるOptimizer Fix Controlsが導入されました。これにより、一部の新しい変更をロールバックしたり、制御したりすることが可能になります。 - 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべてオプティマ[オプティマイザ修正コントロール](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1つ以上の動作の目標値を設定できます。 + 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべて[Optimizer Fix Controls](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1つ以上の動作の目標値を設定できます。 - オプティマイザ修正制御メカニズムを使用すると、TiDBオプティマイザをきめ細かく制御できます。これにより、アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段が提供され、TiDBの安定性が向上します。 + Optimizer Fix Controlsメカニズムを使用すると、TiDBオプティマイザをきめ細かく制御できます。これにより、アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段が提供され、TiDBの安定性が向上します。 詳細については、[ドキュメント](/optimizer-fix-controls.md)を参照してください。 diff --git a/releases/release-7.5.7.md b/releases/release-7.5.7.md index 59bb01428a857..559dc2c56f5e9 100644 --- a/releases/release-7.5.7.md +++ b/releases/release-7.5.7.md @@ -81,7 +81,7 @@ TiDB バージョン: 7.5.7 - `latin1_bin`の比較動作が`utf8mb4_bin`および`utf8_bin` と異なる問題を修正しました [＃60701](https://github.com/pingcap/tidb/issues/60701) @[hawkingrei](https://github.com/hawkingrei) - メタデータロック (MDL) を無効にした後、スキーマバージョン更新に失敗して DDL 操作が停止する問題を修正しました。 [＃61210](https://github.com/pingcap/tidb/issues/61210) @[wjhuang2016](https://github.com/wjhuang2016) - 特定のシナリオでログの秘匿化が有効にならない問題を修正[＃59279](https://github.com/pingcap/tidb/issues/59279) @[tangenta](https://github.com/tangenta) - - 修正コントロール#44855が有効になっている場合にTiDBセッションがクラッシュする可能性がある問題を修正[＃59762](https://github.com/pingcap/tidb/issues/59762) @[winoros](https://github.com/winoros) + - Fix Control #44855が有効になっている場合にTiDBセッションがクラッシュする可能性がある問題を修正[＃59762](https://github.com/pingcap/tidb/issues/59762) @[winoros](https://github.com/winoros) - `IndexLookup`オペレータが`context canceled`エラーに遭遇したときに冗長なログエントリを削除します [＃61072](https://github.com/pingcap/tidb/issues/61072) @[yibin87](https://github.com/yibin87) - 統計の不適切な例外処理により、バックグラウンドタスクがタイムアウトしたときにメモリ内の統計が誤って削除される問題を修正しました[＃57901](https://github.com/pingcap/tidb/issues/57901) @[hawkingrei](https://github.com/hawkingrei) - `ADD UNIQUE INDEX`を実行するとデータの不整合が発生する可能性がある問題を修正[＃60339](https://github.com/pingcap/tidb/issues/60339) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index 402c242b49d3b..e17a1af164be5 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -148,7 +148,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - 取り込みモードで複数のインデックスを同時に追加できるようになりました [＃52596](https://github.com/pingcap/tidb/issues/52596) @[lance6716](https://github.com/lance6716) - システム変数`tidb_service_scope`さまざまな値で構成することをサポートし、分散実行フレームワーク（DXF） の利用率を高めます。 [＃52441](https://github.com/pingcap/tidb/issues/52441) @[ywqzzy](https://github.com/ywqzzy) - 常に`false`である DNF 項目の処理を強化し、そのようなフィルタ条件を直接無視することで、不要なテーブル全体のスキャンを回避します[＃40997](https://github.com/pingcap/tidb/issues/40997) @[Rustin170506](https://github.com/Rustin170506) - - オプティマイザがクエリに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できる場合、オプティマイザがクエリに対してインデックスマージを自動的に選択しないという制限を削除するために、オプティマイザ修正コントロールの使用をサポートします。 [＃52869](https://github.com/pingcap/tidb/issues/52869) @[time-and-fate](https://github.com/time-and-fate) + - オプティマイザがクエリに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できる場合、オプティマイザがクエリに対してインデックスマージを自動的に選択しないという制限を削除するために、Optimizer Fix Controlsの使用をサポートします。 [＃52869](https://github.com/pingcap/tidb/issues/52869) @[time-and-fate](https://github.com/time-and-fate) - コプロセッサー演算子の列`execution info`に`total_kv_read_wall_time`メトリックを追加します。 [＃28937](https://github.com/pingcap/tidb/issues/28937) @[cfzjywxk](https://github.com/cfzjywxk) - リソースコントロールダッシュボードに`RU (max)`メトリックを追加する[＃49318](https://github.com/pingcap/tidb/issues/49318) @[nolouch](https://github.com/nolouch) - リソースロック（RLock）が内に解放されない問題を回避するために、LDAP認証にタイムアウトメカニズムを追加します@[YangKeao](https://github.com/YangKeao) [＃51883](https://github.com/pingcap/tidb/issues/51883) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index b44f7cb5ad396..4b629fbc22bc6 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -304,7 +304,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - 大量のデータをスキャンする際のBatchCopタスク構築の効率を最適化する[#55915](https://github.com/pingcap/tidb/issues/55915) [#55413](https://github.com/pingcap/tidb/issues/55413) @[wshwsh12](https://github.com/wshwsh12) - トランザクションのバッファを最適化して、トランザクション内の書き込みレイテンシーと TiDB の CPU 使用率を削減します [#55287](https://github.com/pingcap/tidb/issues/55287) @[you06](https://github.com/you06) - システム変数`tidb_dml_type`が`"bulk"`に設定されている場合の DML ステートメントの実行パフォーマンスを最適化する [#50215](https://github.com/pingcap/tidb/issues/50215) @[ekexium](https://github.com/ekexium) - - [オプティマイザ修正制御 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザが`estRows`の推定最小値を`1` 。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) + - [Optimizer Fix Control 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザが`estRows`の推定最小値を`1` 。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) - [`mysql.tidb_runaway_queries`](/mysql-schema/mysql-schema.md#system-tables-related-to-runaway-queries)ログ テーブルに書き込み制御を追加し、多数の同時書き込みによって発生するオーバーヘッドを削減します [#54434](https://github.com/pingcap/tidb/issues/54434) @[HuSharp](https://github.com/HuSharp) - 内部テーブルに`Selection` 、 `Projection` 、または`Aggregation`演算子がある場合、デフォルトでインデックス結合をサポートします [#47233](https://github.com/pingcap/tidb/issues/47233) @[winoros](https://github.com/winoros) - 特定のシナリオにおける`DELETE`操作のために TiKV から取得する列の詳細の数を減らし、これらの操作のリソースオーバーヘッドを削減します [#38911](https://github.com/pingcap/tidb/issues/38911) @[winoros](https://github.com/winoros) diff --git a/system-variable-reference.md b/system-variable-reference.md index f12ade7c57aeb..09e224e29c1de 100644 --- a/system-variable-reference.md +++ b/system-variable-reference.md @@ -3044,7 +3044,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [最適なパフォーマンスを得るための TiDB の設定](/tidb-performance-tuning-config.md) - [制御実行計画](/control-execution-plan.md) -- [オプティマイザ修正コントロール](/optimizer-fix-controls.md) +- [Optimizer Fix Controls](/optimizer-fix-controls.md) - [SQL 非プリペアド実行プランキャッシュ](/sql-non-prepared-plan-cache.md) - [システム変数](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) - [TiDB 7.2.0 リリースノート](/releases/release-7.2.0.md) diff --git a/system-variables.md b/system-variables.md index c291d36755614..49d603f508251 100644 --- a/system-variables.md +++ b/system-variables.md @@ -4526,7 +4526,7 @@ mysql> desc select count(distinct a) from test.t; - デフォルト値: `""` - この変数は、オプティマイザの内部動作の一部を制御するために使用されます。 - オプティマイザの動作は、ユーザーシナリオやSQLステートメントによって異なる場合があります。この変数を使用することで、オプティマイザをより細かく制御でき、オプティマイザの動作変更によってアップグレード後に発生するパフォーマンス低下を防ぐことができます。 -- より詳細な概要については、[オプティマイザ修正コントロール](/optimizer-fix-controls.md)を参照してください。 +- より詳細な概要については、[Optimizer Fix Controls](/optimizer-fix-controls.md)を参照してください。 @@ -4539,7 +4539,7 @@ mysql> desc select count(distinct a) from test.t; - デフォルト値: `""` - この変数は、オプティマイザの内部動作の一部を制御するために使用されます。 - オプティマイザの動作は、ユーザーシナリオやSQLステートメントによって異なる場合があります。この変数を使用することで、オプティマイザをより細かく制御でき、オプティマイザの動作変更によってアップグレード後に発生するパフォーマンス低下を防ぐことができます。 -- より詳細な概要については、[オプティマイザ修正コントロール](/optimizer-fix-controls.md)を参照してください。 +- より詳細な概要については、[Optimizer Fix Controls](/optimizer-fix-controls.md)を参照してください。 diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 5f060a35c1a3f..9bd5ba0febaa5 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -27,7 +27,7 @@ TiDBのパフォーマンスを最適化するには、さまざまな設定を TiDBのパフォーマンスを最適化するために、一般的に以下の設定が使用されます。 - [SQLプリペアドプランキャッシュ](/sql-prepared-plan-cache.md)などの実行プランキャッシュ[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)強化します[インスタンスレベルの実行プランキャッシュ](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) -- [オプティマイザ修正コントロール](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 +- [Optimizer Fix Controls](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 - ストレージエンジン[Titan](/storage-engine/titan-overview.md)をより積極的に活用する。 - 書き込み負荷の高いワークロード下でも最適かつ安定したパフォーマンスを確保するために、TiKVの圧縮およびフロー制御の設定を微調整します。 From 95f98ae82d28ef00b04d276d466b3e0d0727d966 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 14:59:01 +0900 Subject: [PATCH 3/5] Revert "i18n(ja): keep "Optimizer Fix Control(s)" feature name in English" This reverts commit 483b9750d217ca52db26937f7c9f8befce048bd3. --- TOC-tidb-cloud-essential.md | 2 +- TOC-tidb-cloud-premium.md | 2 +- TOC-tidb-cloud-starter.md | 2 +- TOC-tidb-cloud.md | 2 +- TOC.md | 2 +- .../multi-column-index-best-practices.md | 6 +++--- control-execution-plan.md | 2 +- explain-index-merge.md | 2 +- optimizer-fix-controls.md | 14 +++++++------- releases/release-6.5.7.md | 2 +- releases/release-7.2.0.md | 8 ++++---- releases/release-7.5.7.md | 2 +- releases/release-8.1.0.md | 2 +- releases/release-8.4.0.md | 2 +- system-variable-reference.md | 2 +- system-variables.md | 4 ++-- tidb-performance-tuning-config.md | 2 +- 17 files changed, 29 insertions(+), 29 deletions(-) diff --git a/TOC-tidb-cloud-essential.md b/TOC-tidb-cloud-essential.md index a45e019c12895..55fe8332881e0 100644 --- a/TOC-tidb-cloud-essential.md +++ b/TOC-tidb-cloud-essential.md @@ -112,7 +112,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [Optimizer Fix Controls](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） diff --git a/TOC-tidb-cloud-premium.md b/TOC-tidb-cloud-premium.md index 639cf07ece373..307dadfa4d2fd 100644 --- a/TOC-tidb-cloud-premium.md +++ b/TOC-tidb-cloud-premium.md @@ -110,7 +110,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [Optimizer Fix Controls](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) diff --git a/TOC-tidb-cloud-starter.md b/TOC-tidb-cloud-starter.md index 50f81f780b788..329ea48b00a4f 100644 --- a/TOC-tidb-cloud-starter.md +++ b/TOC-tidb-cloud-starter.md @@ -106,7 +106,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [Optimizer Fix Controls](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） diff --git a/TOC-tidb-cloud.md b/TOC-tidb-cloud.md index 4df3b36432148..25029852f8109 100644 --- a/TOC-tidb-cloud.md +++ b/TOC-tidb-cloud.md @@ -125,7 +125,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [Optimizer Fix Controls](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [インデックスアドバイザー](/index-advisor.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) diff --git a/TOC.md b/TOC.md index 81ba65dc37046..e146affb1e844 100644 --- a/TOC.md +++ b/TOC.md @@ -296,7 +296,7 @@ - [オプティマイザのヒント](/optimizer-hints.md) - [SQLプラン管理](/sql-plan-management.md) - [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md) - - [Optimizer Fix Controls](/optimizer-fix-controls.md) + - [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [インデックスアドバイザー](/index-advisor.md) - チュートリアル - [1つのリージョンに複数の可用性ゾーンを展開](/multi-data-centers-in-one-city-deployment.md) diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 2580dc783bd3d..27c61bb270f4d 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -17,7 +17,7 @@ aliases: ['/ja/tidb/stable/multi-column-index-best-practices/'] ## 前提条件 {#prerequisites} - マルチ列インデックス機能は、TiDB v8.3 以降のバージョンで使用できます。 -- この機能を使用する前に、 [optimizer fix control **54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 +- この機能を使用する前に、 [オプティマイザ修正制御**54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 ## 背景: 複数列インデックス {#background-multi-column-indexes} @@ -238,7 +238,7 @@ CREATE TABLE t1 ( ### 例2: クエリプラン {#example-2-query-plan} -次のクエリプランは、導出された範囲を示しています。 +次のクエリプランは、派生した範囲を示しています。 ```sql -- Query 5: Conjunctive conditions on (a1, b1) @@ -259,7 +259,7 @@ EXPLAIN FORMAT = "brief" この例では、テーブルには約5億行あります。しかし、この最適化により、TiDBはアクセスを約4,000行、つまり全データのわずか0.0008%に絞り込むことができます。この改良により、クエリのレイテンシーは、最適化を行わない場合の2分以上から数ミリ秒へと大幅に短縮されます。 -このような条件で完全なテーブルスキャンを必要とする MySQL とは異なり、TiDB オプティマイザはこれらの導出された範囲を活用して複雑な行の式を効率的に処理できます。 +このような条件で完全なテーブルスキャンを必要とする MySQL とは異なり、TiDB オプティマイザはこれらの派生範囲を活用して複雑な行式を効率的に処理できます。 ## 結論 {#conclusion} diff --git a/control-execution-plan.md b/control-execution-plan.md index 9f65a232d42c7..56986bbdd97f3 100644 --- a/control-execution-plan.md +++ b/control-execution-plan.md @@ -11,4 +11,4 @@ SQLチューニングの最初の2章では、TiDBの実行計画の理解方法 - しかし、ヒントはSQL文を侵襲的に変更します。場合によっては、ヒントを単純に挿入することはできません。SQL [SQLプラン管理](/sql-plan-management.md)では、TiDBが別の構文を使用して実行計画の生成を非侵襲的に制御する方法と、バックグラウンドで実行計画を自動的に進化させる方法について説明しています。この方法は、バージョンアップグレードやクラスタのパフォーマンス低下によって引き起こされる実行計画の不安定性などの問題に対処するのに役立ちます。 - 最後に、[最適化ルールと式のプッシュダウンのブロックリスト](/blocklist-control-plan.md)でブロックリストの使用方法を学びます。 -上記の方法に加えて、実行計画はいくつかのシステム変数にも影響されます。システムレベルまたはセッションレベルでこれらの変数を変更することで、実行計画の生成を制御できます。v6.5.3およびv7.1.0以降、TiDBは比較的特殊な変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)を導入しました。この変数は複数の制御項目を受け入れることができ、クラスタのアップグレード後にオプティマイザの動作変更によって発生するパフォーマンスの低下を防ぐために、オプティマイザの動作をよりきめ細かく制御できます。詳細については[Optimizer Fix Controls](/optimizer-fix-controls.md)を参照してください。 +上記の方法に加えて、実行計画はいくつかのシステム変数にも影響されます。システムレベルまたはセッションレベルでこれらの変数を変更することで、実行計画の生成を制御できます。v6.5.3およびv7.1.0以降、TiDBは比較的特殊な変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)を導入しました。この変数は複数の制御項目を受け入れることができ、クラスタのアップグレード後にオプティマイザの動作変更によって発生するパフォーマンスの低下を防ぐために、オプティマイザの動作をよりきめ細かく制御できます。詳細については[オプティマイザ修正コントロール](/optimizer-fix-controls.md)を参照してください。 diff --git a/explain-index-merge.md b/explain-index-merge.md index 04a52a5e0805f..4f2cdc1ec962d 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -92,7 +92,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t, idx_a, idx_b, idx_c) */ * FROM t WHERE a > > > - SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用すると、 `tidb_enable_index_merge`設定に関係なく、オプティマイザにインデックスマージを強制的に適用させることができます。フィルタリング条件にプッシュダウンできない式が含まれている場合にインデックスマージを有効にするには、SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用する必要があります。 > -> - [Optimizer Fix Control 52869](/optimizer-fix-controls.md#52869-new-in-v810)が`OFF`に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式（フルテーブルスキャン以外）を選択できるとき、オプティマイザはインデックスマージを自動的には選択しません。インデックスマージを使用するには、オプティマイザヒントを指定する必要があります。v8.5.7以降、この制御のデフォルト値は`ON`に変更されており、これにより前述の制限がデフォルトで解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できるようになります。 +> - [オプティマイザ修正制御 52869](/optimizer-fix-controls.md#52869-new-in-v810)が`OFF`に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式（フルテーブルスキャン以外）を選択できるとき、オプティマイザはインデックスマージを自動的には選択しません。インデックスマージを使用するには、オプティマイザヒントを指定する必要があります。v8.5.7以降、この制御のデフォルト値は`ON`に変更されており、これにより前述の制限がデフォルトで解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できるようになります。 > > - 現時点では、インデックスマージは[一時テーブル](/temporary-tables.md)ではサポートされていません。 > diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index 098d983c81248..5f573f44c60e3 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -1,16 +1,16 @@ --- title: Optimizer Fix Controls -summary: Optimizer Fix Controls機能について学習し、`tidb_opt_fix_control` を使用して TiDB オプティマイザをより細かく制御する方法について説明します。 +summary: オプティマイザ修正制御機能について学習し、tidb_opt_fix_control` を使用して TiDB オプティマイザをより細かく制御する方法について説明します。 --- -# Optimizer Fix Controls {#optimizer-fix-controls} +# オプティマイザ修正コントロール {#optimizer-fix-controls} 製品が継続的に進化するにつれて、TiDBオプティマイザの動作が変化し、より合理的な実行計画が生成されます。しかし、特定のシナリオでは、新しい動作が予期しない結果につながる可能性があります。例えば、 - 一部の動作の効果は特定のシナリオに依存します。ほとんどのシナリオで改善をもたらす変更が、他のシナリオでは後退を引き起こす可能性があります。 - 場合によっては、行動の詳細の変化とその結果の関係が非常に複雑になることがあります。特定の行動の改善が、全体的な退行を引き起こす可能性があります。 -そのため、TiDBは、複数の修正項目に値を設定することで、TiDBオプティマイザの動作をきめ細かく制御できるOptimizer Fix Controls機能を提供しています。このドキュメントでは、Optimizer Fix Controls機能とその使用方法について説明し、TiDBが現在Optimizer Fix Controlsでサポートしているすべての修正項目を一覧表示します。 +そのため、TiDBは、複数の修正項目に値を設定することで、TiDBオプティマイザの動作をきめ細かく制御できるオプティマイザ修正制御機能を提供しています。このドキュメントでは、オプティマイザ修正制御機能とその使用方法について説明し、TiDBが現在オプティマイザ修正制御でサポートしているすべての修正項目を一覧表示します。 ## `tidb_opt_fix_control`の紹介 {#introduction-to-tidb-opt-fix-control} @@ -24,7 +24,7 @@ v6.5.3 および v7.1.0 以降、TiDB は、オプティマイザの動作をよ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; ``` -## Optimizer Fix Controls リファレンス {#optimizer-fix-controls-reference} +## オプティマイザ修正コントロールリファレンス {#optimizer-fix-controls-reference} ### `33031`バージョン8.0.0の新機能 {#33031-new-in-v800} @@ -105,15 +105,15 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `ON`。v8.5.7 より前では、デフォルト値は `OFF` です。 - 可能`OFF`値: `ON` -- このfix controlが `OFF` に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できるとき、オプティマイザはインデックスマージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 -- このfix controlが `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 +- この修正制御が `OFF` に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できるとき、オプティマイザはインデックスマージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 +- この修正制御が `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 ### `54337`バージョン8.3.0の新機能 {#54337-new-in-v830} - デフォルト値: `OFF` - 可能`OFF`値: `ON` - 現在、TiDBオプティマイザは、各接続詞が範囲のリストで構成される複雑な接続詞条件のインデックス範囲の導出に制限があります。これは、一般的な範囲交差を適用することで解決できます。 -- このfix controlを有効にすると、この制限が解除され、オプティマイザは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 +- この修正コントロールを有効にすると、この制限が解除され、オプティマイザは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 ### `56318` {#56318} diff --git a/releases/release-6.5.7.md b/releases/release-6.5.7.md index 55ea21808f578..8f27063a6391e 100644 --- a/releases/release-6.5.7.md +++ b/releases/release-6.5.7.md @@ -21,7 +21,7 @@ TiDB バージョン: 6.5.7 - TiDB - パーティションテーブル[＃47071](https://github.com/pingcap/tidb/issues/47071) での`ANALYZE`操作のメモリ使用量とパフォーマンスを最適化します [＃46804](https://github.com/pingcap/tidb/issues/46804) @[hawkingrei](https://github.com/hawkingrei) [＃47104](https://github.com/pingcap/tidb/issues/47104) - - プランキャッシュをサポートして、Optimizer Fix Controlsを使用して物理的な最適化中に生成された`PointGet`演算子を含む実行計画をキャッシュします。 [＃44830](https://github.com/pingcap/tidb/issues/44830) @[qw4990](https://github.com/qw4990) + - プランキャッシュをサポートして、オプティマイザ修正コントロールを使用して物理的な最適化中に生成された`PointGet`演算子を含む実行計画をキャッシュします。 [＃44830](https://github.com/pingcap/tidb/issues/44830) @[qw4990](https://github.com/qw4990) - 特定のシナリオで`OUTER JOIN`を`INNER JOIN`に変換する能力を強化する[＃49616](https://github.com/pingcap/tidb/issues/49616) @[qw4990](https://github.com/qw4990) - TiFlash diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index 23f17bbee5ce8..a5d024d8f52c9 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -75,13 +75,13 @@ TiDB バージョン: 7.2.0 詳細については、[ドキュメント](/sql-plan-management.md)を参照してください。 -- Optimizer Fix Controlsメカニズムを導入して、オプティマイザの動作をきめ細かく制御できるようにします [#43169](https://github.com/pingcap/tidb/issues/43169) @[time-and-fate](https://github.com/time-and-fate) +- オプティマイザ修正制御メカニズムを導入して、オプティマイザの動作をきめ細かく制御できるようにします [#43169](https://github.com/pingcap/tidb/issues/43169) @[time-and-fate](https://github.com/time-and-fate) - より適切な実行計画を生成するため、TiDB オプティマイザの動作は製品のバージョンアップごとに進化しています。しかし、特定のシナリオでは、変更によってパフォーマンスが低下する場合があります。TiDB v7.2.0 では、オプティマイザの細かい動作を制御できるOptimizer Fix Controlsが導入されました。これにより、一部の新しい変更をロールバックしたり、制御したりすることが可能になります。 + より適切な実行計画を生成するため、TiDB オプティマイザの動作は製品のバージョンアップごとに進化しています。しかし、特定のシナリオでは、変更によってパフォーマンスが低下する場合があります。TiDB v7.2.0 では、オプティマイザの細かい動作を制御できるオプティマイザ修正コントロールが導入されました。これにより、一部の新しい変更をロールバックしたり、制御したりすることが可能になります。 - 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべて[Optimizer Fix Controls](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1つ以上の動作の目標値を設定できます。 + 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべてオプティマ[オプティマイザ修正コントロール](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1つ以上の動作の目標値を設定できます。 - Optimizer Fix Controlsメカニズムを使用すると、TiDBオプティマイザをきめ細かく制御できます。これにより、アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段が提供され、TiDBの安定性が向上します。 + オプティマイザ修正制御メカニズムを使用すると、TiDBオプティマイザをきめ細かく制御できます。これにより、アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段が提供され、TiDBの安定性が向上します。 詳細については、[ドキュメント](/optimizer-fix-controls.md)を参照してください。 diff --git a/releases/release-7.5.7.md b/releases/release-7.5.7.md index 559dc2c56f5e9..59bb01428a857 100644 --- a/releases/release-7.5.7.md +++ b/releases/release-7.5.7.md @@ -81,7 +81,7 @@ TiDB バージョン: 7.5.7 - `latin1_bin`の比較動作が`utf8mb4_bin`および`utf8_bin` と異なる問題を修正しました [＃60701](https://github.com/pingcap/tidb/issues/60701) @[hawkingrei](https://github.com/hawkingrei) - メタデータロック (MDL) を無効にした後、スキーマバージョン更新に失敗して DDL 操作が停止する問題を修正しました。 [＃61210](https://github.com/pingcap/tidb/issues/61210) @[wjhuang2016](https://github.com/wjhuang2016) - 特定のシナリオでログの秘匿化が有効にならない問題を修正[＃59279](https://github.com/pingcap/tidb/issues/59279) @[tangenta](https://github.com/tangenta) - - Fix Control #44855が有効になっている場合にTiDBセッションがクラッシュする可能性がある問題を修正[＃59762](https://github.com/pingcap/tidb/issues/59762) @[winoros](https://github.com/winoros) + - 修正コントロール#44855が有効になっている場合にTiDBセッションがクラッシュする可能性がある問題を修正[＃59762](https://github.com/pingcap/tidb/issues/59762) @[winoros](https://github.com/winoros) - `IndexLookup`オペレータが`context canceled`エラーに遭遇したときに冗長なログエントリを削除します [＃61072](https://github.com/pingcap/tidb/issues/61072) @[yibin87](https://github.com/yibin87) - 統計の不適切な例外処理により、バックグラウンドタスクがタイムアウトしたときにメモリ内の統計が誤って削除される問題を修正しました[＃57901](https://github.com/pingcap/tidb/issues/57901) @[hawkingrei](https://github.com/hawkingrei) - `ADD UNIQUE INDEX`を実行するとデータの不整合が発生する可能性がある問題を修正[＃60339](https://github.com/pingcap/tidb/issues/60339) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index e17a1af164be5..402c242b49d3b 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -148,7 +148,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - 取り込みモードで複数のインデックスを同時に追加できるようになりました [＃52596](https://github.com/pingcap/tidb/issues/52596) @[lance6716](https://github.com/lance6716) - システム変数`tidb_service_scope`さまざまな値で構成することをサポートし、分散実行フレームワーク（DXF） の利用率を高めます。 [＃52441](https://github.com/pingcap/tidb/issues/52441) @[ywqzzy](https://github.com/ywqzzy) - 常に`false`である DNF 項目の処理を強化し、そのようなフィルタ条件を直接無視することで、不要なテーブル全体のスキャンを回避します[＃40997](https://github.com/pingcap/tidb/issues/40997) @[Rustin170506](https://github.com/Rustin170506) - - オプティマイザがクエリに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できる場合、オプティマイザがクエリに対してインデックスマージを自動的に選択しないという制限を削除するために、Optimizer Fix Controlsの使用をサポートします。 [＃52869](https://github.com/pingcap/tidb/issues/52869) @[time-and-fate](https://github.com/time-and-fate) + - オプティマイザがクエリに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できる場合、オプティマイザがクエリに対してインデックスマージを自動的に選択しないという制限を削除するために、オプティマイザ修正コントロールの使用をサポートします。 [＃52869](https://github.com/pingcap/tidb/issues/52869) @[time-and-fate](https://github.com/time-and-fate) - コプロセッサー演算子の列`execution info`に`total_kv_read_wall_time`メトリックを追加します。 [＃28937](https://github.com/pingcap/tidb/issues/28937) @[cfzjywxk](https://github.com/cfzjywxk) - リソースコントロールダッシュボードに`RU (max)`メトリックを追加する[＃49318](https://github.com/pingcap/tidb/issues/49318) @[nolouch](https://github.com/nolouch) - リソースロック（RLock）が内に解放されない問題を回避するために、LDAP認証にタイムアウトメカニズムを追加します@[YangKeao](https://github.com/YangKeao) [＃51883](https://github.com/pingcap/tidb/issues/51883) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 4b629fbc22bc6..b44f7cb5ad396 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -304,7 +304,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - 大量のデータをスキャンする際のBatchCopタスク構築の効率を最適化する[#55915](https://github.com/pingcap/tidb/issues/55915) [#55413](https://github.com/pingcap/tidb/issues/55413) @[wshwsh12](https://github.com/wshwsh12) - トランザクションのバッファを最適化して、トランザクション内の書き込みレイテンシーと TiDB の CPU 使用率を削減します [#55287](https://github.com/pingcap/tidb/issues/55287) @[you06](https://github.com/you06) - システム変数`tidb_dml_type`が`"bulk"`に設定されている場合の DML ステートメントの実行パフォーマンスを最適化する [#50215](https://github.com/pingcap/tidb/issues/50215) @[ekexium](https://github.com/ekexium) - - [Optimizer Fix Control 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザが`estRows`の推定最小値を`1` 。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) + - [オプティマイザ修正制御 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザが`estRows`の推定最小値を`1` 。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) - [`mysql.tidb_runaway_queries`](/mysql-schema/mysql-schema.md#system-tables-related-to-runaway-queries)ログ テーブルに書き込み制御を追加し、多数の同時書き込みによって発生するオーバーヘッドを削減します [#54434](https://github.com/pingcap/tidb/issues/54434) @[HuSharp](https://github.com/HuSharp) - 内部テーブルに`Selection` 、 `Projection` 、または`Aggregation`演算子がある場合、デフォルトでインデックス結合をサポートします [#47233](https://github.com/pingcap/tidb/issues/47233) @[winoros](https://github.com/winoros) - 特定のシナリオにおける`DELETE`操作のために TiKV から取得する列の詳細の数を減らし、これらの操作のリソースオーバーヘッドを削減します [#38911](https://github.com/pingcap/tidb/issues/38911) @[winoros](https://github.com/winoros) diff --git a/system-variable-reference.md b/system-variable-reference.md index 09e224e29c1de..f12ade7c57aeb 100644 --- a/system-variable-reference.md +++ b/system-variable-reference.md @@ -3044,7 +3044,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [最適なパフォーマンスを得るための TiDB の設定](/tidb-performance-tuning-config.md) - [制御実行計画](/control-execution-plan.md) -- [Optimizer Fix Controls](/optimizer-fix-controls.md) +- [オプティマイザ修正コントロール](/optimizer-fix-controls.md) - [SQL 非プリペアド実行プランキャッシュ](/sql-non-prepared-plan-cache.md) - [システム変数](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) - [TiDB 7.2.0 リリースノート](/releases/release-7.2.0.md) diff --git a/system-variables.md b/system-variables.md index 49d603f508251..c291d36755614 100644 --- a/system-variables.md +++ b/system-variables.md @@ -4526,7 +4526,7 @@ mysql> desc select count(distinct a) from test.t; - デフォルト値: `""` - この変数は、オプティマイザの内部動作の一部を制御するために使用されます。 - オプティマイザの動作は、ユーザーシナリオやSQLステートメントによって異なる場合があります。この変数を使用することで、オプティマイザをより細かく制御でき、オプティマイザの動作変更によってアップグレード後に発生するパフォーマンス低下を防ぐことができます。 -- より詳細な概要については、[Optimizer Fix Controls](/optimizer-fix-controls.md)を参照してください。 +- より詳細な概要については、[オプティマイザ修正コントロール](/optimizer-fix-controls.md)を参照してください。 @@ -4539,7 +4539,7 @@ mysql> desc select count(distinct a) from test.t; - デフォルト値: `""` - この変数は、オプティマイザの内部動作の一部を制御するために使用されます。 - オプティマイザの動作は、ユーザーシナリオやSQLステートメントによって異なる場合があります。この変数を使用することで、オプティマイザをより細かく制御でき、オプティマイザの動作変更によってアップグレード後に発生するパフォーマンス低下を防ぐことができます。 -- より詳細な概要については、[Optimizer Fix Controls](/optimizer-fix-controls.md)を参照してください。 +- より詳細な概要については、[オプティマイザ修正コントロール](/optimizer-fix-controls.md)を参照してください。 diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 9bd5ba0febaa5..5f060a35c1a3f 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -27,7 +27,7 @@ TiDBのパフォーマンスを最適化するには、さまざまな設定を TiDBのパフォーマンスを最適化するために、一般的に以下の設定が使用されます。 - [SQLプリペアドプランキャッシュ](/sql-prepared-plan-cache.md)などの実行プランキャッシュ[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)強化します[インスタンスレベルの実行プランキャッシュ](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) -- [Optimizer Fix Controls](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 +- [オプティマイザ修正コントロール](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 - ストレージエンジン[Titan](/storage-engine/titan-overview.md)をより積極的に活用する。 - 書き込み負荷の高いワークロード下でも最適かつ安定したパフォーマンスを確保するために、TiKVの圧縮およびフロー制御の設定を微調整します。 From 7da9b470c1dfe4ecd5322ab18e44f7f34f332cd9 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 15:00:51 +0900 Subject: [PATCH 4/5] i18n(ja): unify the optimizer fix control feature name notation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The general feature name (Optimizer Fix Controls, オプティマイザ修正 コントロール) is a normal translated title, like its sibling TOC entries (SQLプラン管理, etc.) — unifies the two competing pre-existing Japanese renderings (修正制御/修正コントロール) to 修正コントロール everywhere it names the feature/mechanism as a whole (page title, headings, TOC/cross-reference links, mechanism-level release-note prose). A reference to one specific numbered fix control item (e.g. "optimizer fix control 54337", "this fix control", "Fix Control #44855") reads more like an identifier than a title, and EN itself never capitalizes these as the branded feature name — kept/restored to English at each such site for consistency with EN and with pre-existing correctly- English sites found in release-8.5.7.md. The system variable identifier `tidb_opt_fix_control` (backticked, a real system variable) stays literal throughout, as it always has. Also fixes, found along the way: - optimizer-fix-controls.md: a scrambled "Possible values" line (可能`OFF`値: `ON` instead of 可能な値: `ON`、`OFF`) repeated 12 times. - releases/release-7.2.0.md: a stray dangling text fragment before a link. - optimizer-fix-controls.md: a missing opening backtick around `tidb_opt_fix_control` in the frontmatter summary. - best-practices/multi-column-index-best-practices.md: 派生範囲/ 派生した範囲 → 導出された範囲 and 行式 → 行の式, matching this file's own established terminology; also a missing space before a bold numbered fix-control reference. - releases/release-8.5.7.md: a missing space between a Japanese particle and an embedded English phrase. --- .../multi-column-index-best-practices.md | 6 ++-- explain-index-merge.md | 2 +- optimizer-fix-controls.md | 34 +++++++++---------- releases/release-7.2.0.md | 6 ++-- releases/release-7.3.0.md | 2 +- releases/release-7.5.7.md | 2 +- releases/release-8.4.0.md | 2 +- releases/release-8.5.7.md | 2 +- 8 files changed, 28 insertions(+), 28 deletions(-) diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 27c61bb270f4d..2580dc783bd3d 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -17,7 +17,7 @@ aliases: ['/ja/tidb/stable/multi-column-index-best-practices/'] ## 前提条件 {#prerequisites} - マルチ列インデックス機能は、TiDB v8.3 以降のバージョンで使用できます。 -- この機能を使用する前に、 [オプティマイザ修正制御**54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 +- この機能を使用する前に、 [optimizer fix control **54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 ## 背景: 複数列インデックス {#background-multi-column-indexes} @@ -238,7 +238,7 @@ CREATE TABLE t1 ( ### 例2: クエリプラン {#example-2-query-plan} -次のクエリプランは、派生した範囲を示しています。 +次のクエリプランは、導出された範囲を示しています。 ```sql -- Query 5: Conjunctive conditions on (a1, b1) @@ -259,7 +259,7 @@ EXPLAIN FORMAT = "brief" この例では、テーブルには約5億行あります。しかし、この最適化により、TiDBはアクセスを約4,000行、つまり全データのわずか0.0008%に絞り込むことができます。この改良により、クエリのレイテンシーは、最適化を行わない場合の2分以上から数ミリ秒へと大幅に短縮されます。 -このような条件で完全なテーブルスキャンを必要とする MySQL とは異なり、TiDB オプティマイザはこれらの派生範囲を活用して複雑な行式を効率的に処理できます。 +このような条件で完全なテーブルスキャンを必要とする MySQL とは異なり、TiDB オプティマイザはこれらの導出された範囲を活用して複雑な行の式を効率的に処理できます。 ## 結論 {#conclusion} diff --git a/explain-index-merge.md b/explain-index-merge.md index 4f2cdc1ec962d..04a52a5e0805f 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -92,7 +92,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t, idx_a, idx_b, idx_c) */ * FROM t WHERE a > > > - SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用すると、 `tidb_enable_index_merge`設定に関係なく、オプティマイザにインデックスマージを強制的に適用させることができます。フィルタリング条件にプッシュダウンできない式が含まれている場合にインデックスマージを有効にするには、SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用する必要があります。 > -> - [オプティマイザ修正制御 52869](/optimizer-fix-controls.md#52869-new-in-v810)が`OFF`に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式（フルテーブルスキャン以外）を選択できるとき、オプティマイザはインデックスマージを自動的には選択しません。インデックスマージを使用するには、オプティマイザヒントを指定する必要があります。v8.5.7以降、この制御のデフォルト値は`ON`に変更されており、これにより前述の制限がデフォルトで解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できるようになります。 +> - [Optimizer Fix Control 52869](/optimizer-fix-controls.md#52869-new-in-v810)が`OFF`に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式（フルテーブルスキャン以外）を選択できるとき、オプティマイザはインデックスマージを自動的には選択しません。インデックスマージを使用するには、オプティマイザヒントを指定する必要があります。v8.5.7以降、この制御のデフォルト値は`ON`に変更されており、これにより前述の制限がデフォルトで解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できるようになります。 > > - 現時点では、インデックスマージは[一時テーブル](/temporary-tables.md)ではサポートされていません。 > diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index 5f573f44c60e3..6547f0765be2e 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -1,6 +1,6 @@ --- title: Optimizer Fix Controls -summary: オプティマイザ修正制御機能について学習し、tidb_opt_fix_control` を使用して TiDB オプティマイザをより細かく制御する方法について説明します。 +summary: オプティマイザ修正コントロール機能について学習し、`tidb_opt_fix_control` を使用して TiDB オプティマイザをより細かく制御する方法について説明します。 --- # オプティマイザ修正コントロール {#optimizer-fix-controls} @@ -10,7 +10,7 @@ summary: オプティマイザ修正制御機能について学習し、tidb_opt - 一部の動作の効果は特定のシナリオに依存します。ほとんどのシナリオで改善をもたらす変更が、他のシナリオでは後退を引き起こす可能性があります。 - 場合によっては、行動の詳細の変化とその結果の関係が非常に複雑になることがあります。特定の行動の改善が、全体的な退行を引き起こす可能性があります。 -そのため、TiDBは、複数の修正項目に値を設定することで、TiDBオプティマイザの動作をきめ細かく制御できるオプティマイザ修正制御機能を提供しています。このドキュメントでは、オプティマイザ修正制御機能とその使用方法について説明し、TiDBが現在オプティマイザ修正制御でサポートしているすべての修正項目を一覧表示します。 +そのため、TiDBは、複数の修正項目に値を設定することで、TiDBオプティマイザの動作をきめ細かく制御できるオプティマイザ修正コントロール機能を提供しています。このドキュメントでは、オプティマイザ修正コントロール機能とその使用方法について説明し、TiDBが現在オプティマイザ修正コントロールでサポートしているすべての修正項目を一覧表示します。 ## `tidb_opt_fix_control`の紹介 {#introduction-to-tidb-opt-fix-control} @@ -29,19 +29,19 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; ### `33031`バージョン8.0.0の新機能 {#33031-new-in-v800} - デフォルト値: `OFF` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - この変数は、パーティションテーブルに対してプランキャッシュを許可するかどうかを制御します。 `ON`に設定した場合、 [パーティションテーブル](/partitioned-table.md)では[プリペアドステートメントプランキャッシュ](/sql-prepared-plan-cache.md)も[非プリペアドステートメントプランキャッシュ](/sql-non-prepared-plan-cache.md)有効になりません。 ### `44262` v6.5.3 および v7.2.0 の新機能 {#44262-new-in-v653-and-v720} - デフォルト値: `OFF` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - この変数は、パーティションテーブルの[世界統計](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode)が欠落している場合に、 [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を使用してそのテーブルにアクセスできるようにするかどうかを制御します。 ### `44389` v6.5.3 および v7.2.0 の新機能 {#44389-new-in-v653-and-v720} - デフォルト値: `OFF` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - `c = 10 and (a = 'xx' or (a = 'kk' and b = 1))`などのフィルターの場合、この変数は`IndexRangeScan`より包括的なスキャン範囲を構築するかどうかを制御します。 ### `44823`バージョン7.3.0の新機能 {#44823-new-in-v730} @@ -53,13 +53,13 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; ### `44830` v6.5.7 および v7.3.0 の新機能 {#44830-new-in-v657-and-v730} - デフォルト値: `OFF` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - この変数は、物理的な最適化中に生成された`PointGet`演算子を使用して実行計画をプランキャッシュがキャッシュできるかどうかを制御します。 ### `44855` v6.5.4 および v7.3.0 の新機能 {#44855-new-in-v654-and-v730} - デフォルト値: `OFF` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - 一部のシナリオでは、 `IndexJoin`演算子の`Probe`側に`Selection`演算子が含まれている場合、TiDB は行数を`IndexScan`と大幅に過大評価します。その結果、 `IndexJoin`ではなく、最適ではないクエリプランが選択される場合があります。 - この問題を軽減するために、TiDB では改善が導入されました。ただし、クエリプランのフォールバックによる潜在的なリスクがあるため、この改善はデフォルトで無効になっています。 - この変数は、前述の改善を有効にするかどうかを制御します。 @@ -74,19 +74,19 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; ### `45798`バージョン7.5.0の新機能 {#45798-new-in-v750} - デフォルト値: `ON` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - この変数は、プランキャッシュが[生成列](/generated-columns.md)にアクセスする実行計画をキャッシュできるかどうかを制御します。 ### `46177` v6.5.6、v7.1.3、v7.5.0 の新機能 {#46177-new-in-v656-v713-and-v750} - デフォルト値: `ON` 。v8.5.0 より前では、デフォルト値は`OFF`です。 -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - この変数は、強制されていないプランを見つけた後、クエリの最適化中にオプティマイザが強制されているプランを探索するかどうかを制御します。 ### `47400`バージョン8.4.0の新機能 {#47400-new-in-v840} - デフォルト値: `ON` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - クエリプランの各プランステップで適切な行数を正確に推定することは困難であるため、オプティマイザは`estRows`小さく推定する場合があります。この変数は、最小値`estRows`を制限するかどうかを制御します。 - `ON` : 最小値`estRows`を1に制限します。これは、v8.4.0 で導入された新しい動作であり、Oracle や Db2 などの他のデータベースと一致しています。 - `OFF` : 最小行数推定制限を無効にします。これにより、v8.4.0 より前のバージョンとの動作の一貫性が維持されます。この場合、 `estRows` 0 になる可能性があります。 @@ -94,7 +94,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; ### `52592`バージョン8.4.0の新機能 {#52592-new-in-v840} - デフォルト値: `OFF` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - この変数は、クエリ実行時に演算子`Point Get`と`Batch Point Get`を無効にするかどうかを制御します。デフォルト値`OFF`は、演算子`Point Get`と`Batch Point Get`をクエリ実行に使用できることを意味します。`ON`に設定すると、オプティマイザは演算子`Point Get`と`Batch Point Get`を無効にし、クエリ実行にコプロセッサーを強制的に選択します。 - `Point Get`と`Batch Point Get`列投影をサポートしていません（つまり、列のサブセットのみを返すことはできません）。そのため、シナリオによっては、実行効率がコプロセッサーよりも低くなる可能性があります。この変数を`ON`に設定すると、クエリのパフォーマンスが向上します。この変数を`ON`に設定する推奨シナリオは次のとおりです。 @@ -104,16 +104,16 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; ### `52869`バージョン8.1.0の新機能 {#52869-new-in-v810} - デフォルト値: `ON`。v8.5.7 より前では、デフォルト値は `OFF` です。 -- 可能`OFF`値: `ON` -- この修正制御が `OFF` に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できるとき、オプティマイザはインデックスマージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 -- この修正制御が `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 +- 可能な値: `ON`、`OFF` +- このfix controlが `OFF` に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できるとき、オプティマイザはインデックスマージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 +- このfix controlが `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 ### `54337`バージョン8.3.0の新機能 {#54337-new-in-v830} - デフォルト値: `OFF` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - 現在、TiDBオプティマイザは、各接続詞が範囲のリストで構成される複雑な接続詞条件のインデックス範囲の導出に制限があります。これは、一般的な範囲交差を適用することで解決できます。 -- この修正コントロールを有効にすると、この制限が解除され、オプティマイザは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 +- このfix controlを有効にすると、この制限が解除され、オプティマイザは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 ### `56318` {#56318} @@ -122,5 +122,5 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; > これは[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)のみ利用可能です。 - デフォルト値: `ON` -- 可能`OFF`値: `ON` +- 可能な値: `ON`、`OFF` - この変数は`ORDER BY`ステートメントで使用される重い式を 2回計算することを回避するかどうかを制御します。 diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index a5d024d8f52c9..89e4c235d73a6 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -75,13 +75,13 @@ TiDB バージョン: 7.2.0 詳細については、[ドキュメント](/sql-plan-management.md)を参照してください。 -- オプティマイザ修正制御メカニズムを導入して、オプティマイザの動作をきめ細かく制御できるようにします [#43169](https://github.com/pingcap/tidb/issues/43169) @[time-and-fate](https://github.com/time-and-fate) +- オプティマイザ修正コントロールメカニズムを導入して、オプティマイザの動作をきめ細かく制御できるようにします [#43169](https://github.com/pingcap/tidb/issues/43169) @[time-and-fate](https://github.com/time-and-fate) より適切な実行計画を生成するため、TiDB オプティマイザの動作は製品のバージョンアップごとに進化しています。しかし、特定のシナリオでは、変更によってパフォーマンスが低下する場合があります。TiDB v7.2.0 では、オプティマイザの細かい動作を制御できるオプティマイザ修正コントロールが導入されました。これにより、一部の新しい変更をロールバックしたり、制御したりすることが可能になります。 - 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべてオプティマ[オプティマイザ修正コントロール](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1つ以上の動作の目標値を設定できます。 + 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべて[オプティマイザ修正コントロール](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1つ以上の動作の目標値を設定できます。 - オプティマイザ修正制御メカニズムを使用すると、TiDBオプティマイザをきめ細かく制御できます。これにより、アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段が提供され、TiDBの安定性が向上します。 + オプティマイザ修正コントロールメカニズムを使用すると、TiDBオプティマイザをきめ細かく制御できます。これにより、アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段が提供され、TiDBの安定性が向上します。 詳細については、[ドキュメント](/optimizer-fix-controls.md)を参照してください。 diff --git a/releases/release-7.3.0.md b/releases/release-7.3.0.md index f38615f367f36..92143635fd45e 100644 --- a/releases/release-7.3.0.md +++ b/releases/release-7.3.0.md @@ -198,7 +198,7 @@ TiDB バージョン: 7.3.0 - [グローバルキル](/tidb-configuration-file.md#enable-global-kill-new-in-v610)が有効な場合、 Ctrl+Cを押すと現在のセッションを終了できます [#8854](https://github.com/pingcap/tidb/issues/8854) @[pingyu](https://github.com/pingyu) - `IS_FREE_LOCK()`および`IS_USED_LOCK()`のロック関数をサポートする [#44493](https://github.com/pingcap/tidb/issues/44493) @[dveeden](https://github.com/dveeden) - ディスクからダンプされたチャンクを読み取るパフォーマンスを最適化 [#45125](https://github.com/pingcap/tidb/issues/45125) @[YangKeao](https://github.com/YangKeao) - - Optimizer Fix Controls を使用してインデックス結合の内部テーブルの過大評価問題を最適化する [#44855](https://github.com/pingcap/tidb/issues/44855) @[time-and-fate](https://github.com/time-and-fate) + - オプティマイザ修正コントロールを使用してインデックス結合の内部テーブルの過大評価問題を最適化する [#44855](https://github.com/pingcap/tidb/issues/44855) @[time-and-fate](https://github.com/time-and-fate) - TiKV diff --git a/releases/release-7.5.7.md b/releases/release-7.5.7.md index 59bb01428a857..559dc2c56f5e9 100644 --- a/releases/release-7.5.7.md +++ b/releases/release-7.5.7.md @@ -81,7 +81,7 @@ TiDB バージョン: 7.5.7 - `latin1_bin`の比較動作が`utf8mb4_bin`および`utf8_bin` と異なる問題を修正しました [＃60701](https://github.com/pingcap/tidb/issues/60701) @[hawkingrei](https://github.com/hawkingrei) - メタデータロック (MDL) を無効にした後、スキーマバージョン更新に失敗して DDL 操作が停止する問題を修正しました。 [＃61210](https://github.com/pingcap/tidb/issues/61210) @[wjhuang2016](https://github.com/wjhuang2016) - 特定のシナリオでログの秘匿化が有効にならない問題を修正[＃59279](https://github.com/pingcap/tidb/issues/59279) @[tangenta](https://github.com/tangenta) - - 修正コントロール#44855が有効になっている場合にTiDBセッションがクラッシュする可能性がある問題を修正[＃59762](https://github.com/pingcap/tidb/issues/59762) @[winoros](https://github.com/winoros) + - Fix Control #44855が有効になっている場合にTiDBセッションがクラッシュする可能性がある問題を修正[＃59762](https://github.com/pingcap/tidb/issues/59762) @[winoros](https://github.com/winoros) - `IndexLookup`オペレータが`context canceled`エラーに遭遇したときに冗長なログエントリを削除します [＃61072](https://github.com/pingcap/tidb/issues/61072) @[yibin87](https://github.com/yibin87) - 統計の不適切な例外処理により、バックグラウンドタスクがタイムアウトしたときにメモリ内の統計が誤って削除される問題を修正しました[＃57901](https://github.com/pingcap/tidb/issues/57901) @[hawkingrei](https://github.com/hawkingrei) - `ADD UNIQUE INDEX`を実行するとデータの不整合が発生する可能性がある問題を修正[＃60339](https://github.com/pingcap/tidb/issues/60339) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index b44f7cb5ad396..4b629fbc22bc6 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -304,7 +304,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - 大量のデータをスキャンする際のBatchCopタスク構築の効率を最適化する[#55915](https://github.com/pingcap/tidb/issues/55915) [#55413](https://github.com/pingcap/tidb/issues/55413) @[wshwsh12](https://github.com/wshwsh12) - トランザクションのバッファを最適化して、トランザクション内の書き込みレイテンシーと TiDB の CPU 使用率を削減します [#55287](https://github.com/pingcap/tidb/issues/55287) @[you06](https://github.com/you06) - システム変数`tidb_dml_type`が`"bulk"`に設定されている場合の DML ステートメントの実行パフォーマンスを最適化する [#50215](https://github.com/pingcap/tidb/issues/50215) @[ekexium](https://github.com/ekexium) - - [オプティマイザ修正制御 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザが`estRows`の推定最小値を`1` 。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) + - [Optimizer Fix Control 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザが`estRows`の推定最小値を`1` 。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) - [`mysql.tidb_runaway_queries`](/mysql-schema/mysql-schema.md#system-tables-related-to-runaway-queries)ログ テーブルに書き込み制御を追加し、多数の同時書き込みによって発生するオーバーヘッドを削減します [#54434](https://github.com/pingcap/tidb/issues/54434) @[HuSharp](https://github.com/HuSharp) - 内部テーブルに`Selection` 、 `Projection` 、または`Aggregation`演算子がある場合、デフォルトでインデックス結合をサポートします [#47233](https://github.com/pingcap/tidb/issues/47233) @[winoros](https://github.com/winoros) - 特定のシナリオにおける`DELETE`操作のために TiKV から取得する列の詳細の数を減らし、これらの操作のリソースオーバーヘッドを削減します [#38911](https://github.com/pingcap/tidb/issues/38911) @[winoros](https://github.com/winoros) diff --git a/releases/release-8.5.7.md b/releases/release-8.5.7.md index 326fe8d275bf2..d720ba4d6a19e 100644 --- a/releases/release-8.5.7.md +++ b/releases/release-8.5.7.md @@ -175,7 +175,7 @@ v8.5.6 で新規にデプロイされた TiDB クラスター（つまり、以 - 推定 probe 行数が全スキャンに近い場合に非効率な index join を選択しないよう join プラン選択を改善し、一部の `HASHAGG` + join シナリオでクエリパフォーマンスを向上しました。[#67610](https://github.com/pingcap/tidb/issues/67610) @[qw4990](https://github.com/qw4990) - ネストした `OR` 条件を含むクエリについて、より効率的な `IndexMerge` プランを有効にし、冗長なグローバルフィルターを削除して `LIMIT` をプッシュダウンできるようにすることで、クエリパフォーマンスを改善しました。[#65822](https://github.com/pingcap/tidb/issues/65822) @[time-and-fate](https://github.com/time-and-fate) - [`FLUSH STATS_DELTA`](https://docs.pingcap.com/tidb/v8.5/sql-statement-flush-stats-delta) 文をサポートし、クラスター、データベース単位、またはテーブル単位のスコープについて、保留中のオプティマイザ統計デルタを永続化できるようにしました。[#65668](https://github.com/pingcap/tidb/issues/65668) @[0xPoe](https://github.com/0xPoe) - - 代替インデックスが存在する場合に `IndexMerge` を考慮するためのoptimizer fix control をデフォルトで有効にし、より多くの適用可能なクエリで TiDB が `IndexMerge` プランを選択できるようにして、クエリ最適化を改善しました。[#26764](https://github.com/pingcap/tidb/issues/26764) @[time-and-fate](https://github.com/time-and-fate) + - 代替インデックスが存在する場合に `IndexMerge` を考慮するための optimizer fix control をデフォルトで有効にし、より多くの適用可能なクエリで TiDB が `IndexMerge` プランを選択できるようにして、クエリ最適化を改善しました。[#26764](https://github.com/pingcap/tidb/issues/26764) @[time-and-fate](https://github.com/time-and-fate) - `set_var` および `resource_group` ヒントを使用するプリペアドクエリと非プリペアドクエリのキャッシュをサポートし、ヒント付きクエリのプランキャッシュヒット率を向上しました。[#60920](https://github.com/pingcap/tidb/issues/60920) @[qw4990](https://github.com/qw4990) - `IndexMerge` を使用する `ORDER BY ... LIMIT` および `ORDER BY ... TOPN` クエリを最適化し、可能な場合は `Limit` または `TopN` を個々の部分パスにプッシュダウンすることで、一部のクエリプランにおける不要なスキャンとソートを削減しました。[#68773](https://github.com/pingcap/tidb/issues/68773) @[time-and-fate](https://github.com/time-and-fate) - 新規に bootstrap されたクラスターにおける `ANALYZE` パフォーマンスを改善するため、`mysql.stats_*` システムテーブルに clustered primary key を使用するようにしました。[#66751](https://github.com/pingcap/tidb/issues/66751) @[0xPoe](https://github.com/0xPoe) From 9334db91708f0cead2ff686d9f081ff32ee71f77 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 15:31:28 +0900 Subject: [PATCH 5/5] i18n(ja): fix defects found by CodeRabbit review - agg-distinct-optimization.md: restore a missing opening backtick around distinct, and fix a clause-ordering mistranslation that misattributed "for aggregate functions" to the wrong DISTINCT form. - releases/release-8.4.0.md: complete a dangling sentence about the estRows minimum-value fix control, reusing the phrasing already established on optimizer-fix-controls.md's own entry for the same fix number. - releases/release-7.3.0.md: reword an awkward "optimize the ... issue" translation to the more natural "improve the overestimation". --- agg-distinct-optimization.md | 4 ++-- releases/release-7.3.0.md | 2 +- releases/release-8.4.0.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/agg-distinct-optimization.md b/agg-distinct-optimization.md index 555d0879ab9a8..1c92b0e93c1b7 100644 --- a/agg-distinct-optimization.md +++ b/agg-distinct-optimization.md @@ -1,11 +1,11 @@ --- title: Distinct Optimization -summary: TiDB クエリ オプティマイザに distinct` 最適化を導入します。 +summary: TiDB クエリ オプティマイザに`distinct`最適化を導入します。 --- # クエリの最適化 {#distinct-optimization} -このドキュメントでは、集計関数の`SELECT DISTINCT`と`DISTINCT`含む、TiDB クエリ オプティマイザの`distinct`最適化について説明します。 +このドキュメントでは、`SELECT DISTINCT`および集計関数の`DISTINCT`オプションを含む、TiDB クエリ オプティマイザの`distinct`最適化について説明します。 ## `SELECT`文の`DISTINCT`修飾子 {#distinct-modifier-in-select-statements} diff --git a/releases/release-7.3.0.md b/releases/release-7.3.0.md index 92143635fd45e..84c6d1648a681 100644 --- a/releases/release-7.3.0.md +++ b/releases/release-7.3.0.md @@ -198,7 +198,7 @@ TiDB バージョン: 7.3.0 - [グローバルキル](/tidb-configuration-file.md#enable-global-kill-new-in-v610)が有効な場合、 Ctrl+Cを押すと現在のセッションを終了できます [#8854](https://github.com/pingcap/tidb/issues/8854) @[pingyu](https://github.com/pingyu) - `IS_FREE_LOCK()`および`IS_USED_LOCK()`のロック関数をサポートする [#44493](https://github.com/pingcap/tidb/issues/44493) @[dveeden](https://github.com/dveeden) - ディスクからダンプされたチャンクを読み取るパフォーマンスを最適化 [#45125](https://github.com/pingcap/tidb/issues/45125) @[YangKeao](https://github.com/YangKeao) - - オプティマイザ修正コントロールを使用してインデックス結合の内部テーブルの過大評価問題を最適化する [#44855](https://github.com/pingcap/tidb/issues/44855) @[time-and-fate](https://github.com/time-and-fate) + - オプティマイザ修正コントロールを使用して、インデックス結合の内部テーブルの過大評価を改善する [#44855](https://github.com/pingcap/tidb/issues/44855) @[time-and-fate](https://github.com/time-and-fate) - TiKV diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 4b629fbc22bc6..f139abef58b20 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -304,7 +304,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - 大量のデータをスキャンする際のBatchCopタスク構築の効率を最適化する[#55915](https://github.com/pingcap/tidb/issues/55915) [#55413](https://github.com/pingcap/tidb/issues/55413) @[wshwsh12](https://github.com/wshwsh12) - トランザクションのバッファを最適化して、トランザクション内の書き込みレイテンシーと TiDB の CPU 使用率を削減します [#55287](https://github.com/pingcap/tidb/issues/55287) @[you06](https://github.com/you06) - システム変数`tidb_dml_type`が`"bulk"`に設定されている場合の DML ステートメントの実行パフォーマンスを最適化する [#50215](https://github.com/pingcap/tidb/issues/50215) @[ekexium](https://github.com/ekexium) - - [Optimizer Fix Control 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザが`estRows`の推定最小値を`1` 。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) + - [Optimizer Fix Control 47400](/optimizer-fix-controls.md#47400-new-in-v840)の使用をサポートし、オプティマイザが`estRows`の推定最小値を`1`に制限するかどうかを制御できるようにします。これは、Oracle や Db2 などのデータベースと一貫性があります [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) - [`mysql.tidb_runaway_queries`](/mysql-schema/mysql-schema.md#system-tables-related-to-runaway-queries)ログ テーブルに書き込み制御を追加し、多数の同時書き込みによって発生するオーバーヘッドを削減します [#54434](https://github.com/pingcap/tidb/issues/54434) @[HuSharp](https://github.com/HuSharp) - 内部テーブルに`Selection` 、 `Projection` 、または`Aggregation`演算子がある場合、デフォルトでインデックス結合をサポートします [#47233](https://github.com/pingcap/tidb/issues/47233) @[winoros](https://github.com/winoros) - 特定のシナリオにおける`DELETE`操作のために TiKV から取得する列の詳細の数を減らし、これらの操作のリソースオーバーヘッドを削減します [#38911](https://github.com/pingcap/tidb/issues/38911) @[winoros](https://github.com/winoros)