i18n(ja): unify the optimizer fix control feature name notation

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）

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)

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）

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)

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)

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}
 

analyze-slow-queries.md

@@ -16,16 +16,16 @@ summary: スロークエリを見つけて分析する方法を学びます。
 
 一般的に、クエリが遅くなる主な原因は次のとおりです。
 
-- 間違ったインデックスが選択された、間違った結合タイプまたはシーケンスが選択されたなどのオプティマイザーの問題。
-- システムの問題。オプティマイザーが原因ではない問題はすべてシステムの問題です。例えば、TiKVインスタンスがビジー状態だとリクエストの処理が遅くなったり、リージョン情報が古くなるとクエリが遅くなったりします。
+- 間違ったインデックスが選択された、間違った結合タイプまたはシーケンスが選択されたなどのオプティマイザの問題。
+- システムの問題。オプティマイザが原因ではない問題はすべてシステムの問題です。例えば、TiKVインスタンスがビジー状態だとリクエストの処理が遅くなったり、リージョン情報が古くなるとクエリが遅くなったりします。
 
 実際の状況では、オプティマイザの問題がシステムの問題を引き起こす可能性があります。例えば、特定の種類のクエリでは、オプティマイザはインデックスではなくフルテーブルスキャンを使用します。その結果、SQLクエリが多くのリソースを消費し、一部のTiKVインスタンスのCPU使用率が急上昇します。これはシステムの問題のように見えますが、実際にはオプティマイザの問題です。
 
 システムの問題を特定するのは比較的簡単です。オプティマイザの問題を分析するには、実行計画が妥当かどうかを判断する必要があります。そのため、以下の手順に従ってスロークエリを分析することをお勧めします。
 
 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)で説明されています。解決策については、以下のドキュメントを参照してください。
 

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)のコマンドでダウンロードできます。
 

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% 向上することがわかります。

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データベースでは、分散クエリの規模と複数ノード間の調整の複雑さにより、インデックス作成の非効率性の影響はさらに大きくなります。そのため、データベースを最適化した状態に保つには、定期的なインデックス監査が不可欠です。
 

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`に設定する必要があります。
+- この機能を使用する前に、 [optimizer fix control **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`より小さい場合をカバーします。
@@ -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}