i18n(ja): remove spurious 番目/目 ordinals mistranslated from "the X <noun>"

ai/guides/vector-search.md

@@ -323,7 +323,7 @@ results = (
 
 > **Note:**
 >
-> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。3 `.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`番目のパラメータを変更せずに制御できます。
+> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。3 `.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`パラメータを変更せずに制御できます。
 
 > `num_candidate`値を大きくすると、一般的に再現率は向上しますが、クエリのパフォーマンスが低下する可能性があります。データセットと精度要件に応じてこの値を調整してください。
 

auto-increment.md

@@ -27,7 +27,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。
 
 ## コンセプト {#concept}
 
-`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。2 `INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。
+`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。2 `INSERT`ステートメントで`AUTO_INCREMENT`列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。
 
 パフォーマンス上の理由から、各TiDBサーバーには、 `AUTO_INCREMENT`個の数値が一括で割り当てられます（デフォルトでは3万個）。つまり、 `AUTO_INCREMENT`数値は一意であることが保証されますが、 `INSERT`ステートメントに割り当てられる値は、TiDBサーバーごとに単調なものになります。
 
@@ -100,7 +100,7 @@ CREATE TABLE t(id int UNIQUE KEY AUTO_INCREMENT, c int);
 INSERT INTO t (c) VALUES (1)
 ```
 
-インスタンス`A` `[1,30000]`のAUTO_INCREMENT ID をキャッシュし、インスタンス`B` `[30001,60000]`のAUTO_INCREMENT ID をキャッシュしている可能性があります。実行される`INSERT`ステートメントでは、各インスタンスのキャッシュされた ID が`AUTO_INCREMENT`番目の列にデフォルト値として割り当てられます。
+インスタンス`A` `[1,30000]`のAUTO_INCREMENT ID をキャッシュし、インスタンス`B` `[30001,60000]`のAUTO_INCREMENT ID をキャッシュしている可能性があります。実行される`INSERT`ステートメントでは、各インスタンスのキャッシュされた ID が`AUTO_INCREMENT`列にデフォルト値として割り当てられます。
 
 ## 基本機能 {#basic-features}
 
@@ -183,7 +183,7 @@ Records: 2  Duplicates: 1  Warnings: 0
 
 ## 自動IDキャッシュ {#auto-id-cache}
 
-異なるTiDBサーバーに対して`INSERT`操作を実行すると、 `AUTO_INCREMENT`番目のシーケンスが大幅に*ジャンプする*ように見える場合があります。これは、各サーバーが`AUTO_INCREMENT`の値のキャッシュを独自に持っているためです。
+異なるTiDBサーバーに対して`INSERT`操作を実行すると、 `AUTO_INCREMENT`シーケンスが大幅に*ジャンプする*ように見える場合があります。これは、各サーバーが`AUTO_INCREMENT`の値のキャッシュを独自に持っているためです。
 
 ```sql
 CREATE TABLE t (a int PRIMARY KEY AUTO_INCREMENT, b timestamp NOT NULL DEFAULT NOW());
@@ -467,6 +467,6 @@ IDは常に増加し、 `AUTO_ID_CACHE 0`のような大きなギャップは発
 -   `INTEGER` 、 `FLOAT` 、または`DOUBLE`タイプの列に定義する必要があります。
 -   `DEFAULT`列の値と同じ列には指定できません。
 -   `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`を使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`を使用することも含まれます。
--   `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`を使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用して`AUTO_INCREMENT`番目の属性を削除することはできません。
+-   `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`を使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用して`AUTO_INCREMENT`属性を削除することはできません。
 -   `ALTER TABLE` 、 `AUTO_INCREMENT`値を小さい値に設定するには`FORCE`オプションが必要です。
 -   `AUTO_INCREMENT` `MAX(<auto_increment_column>)`より小さい値に設定すると、既存の値がスキップされないため、キーが重複することになります。

best-practices/ddl-introduction.md

@@ -161,7 +161,7 @@ TiDB v6.2.0以降、単一の`ALTER`文でテーブル内の複数のスキー
 
 ### 読み取りと書き込みのパフォーマンスを確認する {#check-the-read-and-write-performance}
 
-TiDBがインデックスを追加する際、データのバックフィルフェーズによってクラスターの読み取りと書き込みに負荷がかかります。1 `ADD INDEX`のコマンドが送信され、 `write reorg`番目のフェーズが開始されたら、GrafanaダッシュボードでTiDBとTiKVの読み取りと書き込みのパフォーマンスメトリックとアプリケーションの応答時間を確認し、 `ADD INDEX`操作がクラスターに影響を与えているかどうかを確認することをお勧めします。
+TiDBがインデックスを追加する際、データのバックフィルフェーズによってクラスターの読み取りと書き込みに負荷がかかります。1 `ADD INDEX`のコマンドが送信され、 `write reorg`フェーズが開始されたら、GrafanaダッシュボードでTiDBとTiKVの読み取りと書き込みのパフォーマンスメトリックとアプリケーションの応答時間を確認し、 `ADD INDEX`操作がクラスターに影響を与えているかどうかを確認することをお勧めします。
 
 ## DDL関連コマンド {#ddl-related-commands}
 

blocklist-control-plan.md

@@ -132,7 +132,7 @@ DESC mysql.expr_pushdown_blacklist;
 
 ブロックリストが有効になっているかどうかを判断するには、 `EXPLAIN`の結果を観察します（ [TiDB クエリ実行プランの概要](/explain-overview.md)を参照）。
 
-1.  次の SQL ステートメントの`WHERE`番目の句の述語`a < 2`と`a > 2` 、TiKV にプッシュダウンできます。
+1.  次の SQL ステートメントの`WHERE`句の述語`a < 2`と`a > 2` 、TiKV にプッシュダウンできます。
 
     ```sql
     EXPLAIN SELECT * FROM t WHERE a < 2 AND a > 2;

br/br-pitr-guide.md

@@ -52,7 +52,7 @@ tiup br log status --task-name=pitr --pd "${PD_IP}:2379"
 -   `start` : ログ バックアップ タスクの開始タイムスタンプ。
 -   `end` : ログバックアップタスクの終了タイムスタンプ。現在、このフィールドは無効です。
 -   `storage` : ログ バックアップの外部ストレージの URI。
--   `speed(est.)` : ログバックアップの現在のデータ転送速度。この値は、過去数秒間に取得されたトラフィックサンプルに基づいて推定されます。より正確なトラフィック統計情報については、Grafanaの**<a href="/grafana-tikv-dashboard.md#tikv-details-dashboard">TiKV-Details</a>**ダッシュボードの`Log Backup`行目を確認してください。
+-   `speed(est.)` : ログバックアップの現在のデータ転送速度。この値は、過去数秒間に取得されたトラフィックサンプルに基づいて推定されます。より正確なトラフィック統計情報については、Grafanaの**<a href="/grafana-tikv-dashboard.md#tikv-details-dashboard">TiKV-Details</a>**ダッシュボードの`Log Backup`行を確認してください。
 -   `checkpoint[global]` : ログバックアップの現在の進行状況。PITRを使用して、このタイムスタンプより前の時点に復元できます。
 
 ログバックアップタスクが一時停止されている場合、 `log status`コマンドは一時停止の詳細を表示するための追加フィールドを出力します。これらは次のとおりです。

br/br-pitr-manual.md

@@ -547,9 +547,9 @@ tiup br restore point --pd="${PD_IP}:2379" \
 > -   フィルター オプションは、スナップショット バックアップとログ バックアップの両方の復元フェーズ中に適用されます。
 > -   複数の`--filter`オプションを指定して、異なるパターンを含めたり除外したりできます。
 > -   PITRフィルタリングはシステムテーブルをまだサポートしていません。特定のシステムテーブルを復元する必要がある場合は、代わりにフィルターを指定した`br restore full`コマンドを使用してください。このコマンドはスナップショットバックアップデータのみを復元し、ログバックアップデータは復元しないことに注意してください。
-> -   復元タスク内の正規表現は、 `restored-ts`番目の時点でのテーブル名と一致し、次の 3 つのケースが考えられます。
->     -   テーブルA（テーブルID = 1）：テーブル名は、 `restored-ts`番目の時点以前において、常に`--filter`正規表現と一致します。この場合、PITRはテーブルを復元します。
->     -   テーブルB（テーブルID = 2）：テーブル名は`restored-ts`より前の時点では`--filter`正規表現と一致しませんでしたが、 `restored-ts`番目の時点では一致しました。この場合、PITRはテーブルを復元します。
+> -   復元タスク内の正規表現は、 `restored-ts`時点でのテーブル名と一致し、次の 3 つのケースが考えられます。
+>     -   テーブルA（テーブルID = 1）：テーブル名は、 `restored-ts`時点以前において、常に`--filter`正規表現と一致します。この場合、PITRはテーブルを復元します。
+>     -   テーブルB（テーブルID = 2）：テーブル名は`restored-ts`より前の時点では`--filter`正規表現と一致しませんでしたが、 `restored-ts`時点では一致しました。この場合、PITRはテーブルを復元します。
 >     -   テーブルC（テーブルID = 3）：テーブル名は、 `restored-ts`より前の時点では正規表現`--filter`と一致していましたが、 `restored-ts`時点では一致**していません**。この場合、PITRはテーブルを復元しませ**ん**。
 > -   データベースとテーブルのフィルタリング機能を使用して、データの一部をオンラインで復元できます。オンライン復元プロセス中は、復元されたオブジェクトと同じ名前のデータベースまたはテーブルを作成し**ないで**ください。そうしないと、競合が発生して復元タスクが失敗します。データの不整合を回避するため、この復元プロセス中にPITRによって作成されたテーブルは、復元タスクが完了するまで読み取りも書き込みもできません。
 

cached-tables.md

@@ -53,7 +53,7 @@ Query OK, 0 rows affected (0.01 sec)
 
 ### キャッシュされたテーブルを検証する {#verify-a-cached-table}
 
-キャッシュされたテーブルを検証するには、 `SHOW CREATE TABLE`ステートメントを使用します。テーブルがキャッシュされている場合、返される結果には`CACHED ON`番目の属性が含まれます。
+キャッシュされたテーブルを検証するには、 `SHOW CREATE TABLE`ステートメントを使用します。テーブルがキャッシュされている場合、返される結果には`CACHED ON`属性が含まれます。
 
 ```sql
 SHOW CREATE TABLE users;

constraints.md

@@ -315,7 +315,7 @@ INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill');
 
         ERROR 8147 (23000): transaction aborted because lazy uniqueness check is enabled and an error occurred: [kv:1062]Duplicate entry 'bill' for key 'users.username'
 
--   この変数が無効になっている場合、 `1062 Duplicate entry`エラーは現在の SQL 文に起因しない可能性があります。そのため、トランザクションが同じ名前のインデックスを持つ複数のテーブルを操作する場合、 `1062`番目のエラーメッセージを確認して、実際にどのインデックスにエラーが発生しているかを特定する必要があります。
+-   この変数が無効になっている場合、 `1062 Duplicate entry`エラーは現在の SQL 文に起因しない可能性があります。そのため、トランザクションが同じ名前のインデックスを持つ複数のテーブルを操作する場合、 `1062`エラーメッセージを確認して、実際にどのインデックスにエラーが発生しているかを特定する必要があります。
 
 ## 主キー {#primary-key}
 

dashboard/dashboard-key-visualizer.md

@@ -114,7 +114,7 @@ Key Visualizer を開くと、デフォルトで過去 6 時間のデータベ
 
 ![Select metrics](/media/dashboard/dashboard-keyviz-select-type.png)
 
-関心のあるメトリックを表示するには**、メトリック選択ボックス**(上記のインターフェイスの`Write (bytes)`番目の位置) でこのメトリックを選択します。
+関心のあるメトリックを表示するには**、メトリック選択ボックス**(上記のインターフェイスの`Write (bytes)`の位置) でこのメトリックを選択します。
 
 -   `Read (bytes)` : トラフィックを読み取ります。
 -   `Write (bytes)` : トラフィックを書き込みます。

dashboard/dashboard-metrics-relation.md

@@ -64,11 +64,11 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー
 
 さらに、 `tidb_execute`は`tidb_cop`ボックス領域を指す点線の矢印もあり、次のことを示しています。
 
-`tidb_execute` `tidb_cop`番目のメトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2 つのテーブルに対して`join`クエリを実行する`execute`番目の実行時間は 60 秒ですが、その間に結合した 2 つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。10 `cop`のリクエストの実行時間がそれぞれ 40 秒と 30 秒の場合、 `cop`のリクエストの合計実行時間は 70 秒になります。しかし、 `execute`実行時間はわずか 60 秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。
+`tidb_execute` `tidb_cop`メトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2 つのテーブルに対して`join`クエリを実行する`execute`実行時間は 60 秒ですが、その間に結合した 2 つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。10 `cop`のリクエストの実行時間がそれぞれ 40 秒と 30 秒の場合、 `cop`のリクエストの合計実行時間は 70 秒になります。しかし、 `execute`実行時間はわずか 60 秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。
 
 > **Note:**
 >
-> ノードに子ノードを指す点線矢印がある場合、そのノード自体の持続時間は不正確です。例えば、 `tidb_execute`のノードの場合、ノード自体の持続時間は9070.18秒（ `9070.18 = 19306.46 - 300.66 - 9935.62` ）です。この式では、 `tidb_cop`子ノードの持続時間は`tidb_execute`番目の子ノードの持続時間に含まれていません。しかし、実際にはそうではありません。9番目のノード自体の持続時間である9070.18秒には、 `tidb_cop` `tidb_execute`ノードの持続時間の一部が含まれており、この部分の持続時間は特定できません。
+> ノードに子ノードを指す点線矢印がある場合、そのノード自体の持続時間は不正確です。例えば、 `tidb_execute`のノードの場合、ノード自体の持続時間は9070.18秒（ `9070.18 = 19306.46 - 300.66 - 9935.62` ）です。この式では、 `tidb_cop`子ノードの持続時間は`tidb_execute`の子ノードの持続時間に含まれていません。しかし、実際にはそうではありません。9番目のノード自体の持続時間である9070.18秒には、 `tidb_cop` `tidb_execute`ノードの持続時間の一部が含まれており、この部分の持続時間は特定できません。
 
 ### <code>tidb_kv_request</code>とその親ノード {#code-tidb-kv-request-code-and-its-parent-nodes}
 

develop/dev-guide-hybrid-oltp-and-olap-queries.md

@@ -57,7 +57,7 @@ FROM orders_group_by_month
 ORDER BY month ASC;
 ```
 
-`sum()`番目の関数は、 `OVER`番目の節の`ORDER BY`番目の文で指定された順序でデータを累積します。結果は次のようになります。
+`sum()`関数は、 `OVER`節の`ORDER BY`文で指定された順序でデータを累積します。結果は次のようになります。
 
     +---------+-------+
     | month   | acc   |