i18n(ja): remove stray digits inserted before code spans

CONTRIBUTING.md

@@ -121,7 +121,7 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ
 ### ステップ8: プルリクエストを作成する {#step-8-create-a-pull-request}
 
 1.  [https://github.com/$user/docs](https://github.com/$user/docs)でフォークにアクセスします ( `$user` GitHub ID に置き換えます)
-2.  `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。5 [プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)参照してください。
+2.  `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。詳細は[プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)を参照してください。
 
 これで、PR が正常に送信されました。この PR がマージされると、自動的に TiDB ドキュメントの貢献者になります。
 

agg-distinct-optimization.md

@@ -39,7 +39,7 @@ TiDB の[`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distin
 
 </CustomContent>
 
-この最適化の例として、以下のクエリを見てみましょう。1 `tidb_opt_distinct_agg_push_down`デフォルトで無効になっており、集計関数はTiDBレイヤーで実行されます。この最適化を有効にするために値を`1`に設定すると、 `count(distinct a)`の`distinct a`部分が TiKV またはTiFlashコプロセッサーにプッシュされます。TiKVコプロセッサーには、列 a の重複値を削除する HashAgg_5 があります。これにより、TiDBレイヤーにおける`HashAgg_8`の計算オーバーヘッドが削減される可能性があります。
+この最適化の例として、以下のクエリを見てみましょう。`tidb_opt_distinct_agg_push_down`デフォルトで無効になっており、集計関数はTiDBレイヤーで実行されます。この最適化を有効にするために値を`1`に設定すると、 `count(distinct a)`の`distinct a`部分が TiKV またはTiFlashコプロセッサーにプッシュされます。TiKVコプロセッサーには、列 a の重複値を削除する HashAgg_5 があります。これにより、TiDBレイヤーにおける`HashAgg_8`の計算オーバーヘッドが削減される可能性があります。
 
 ```sql
 mysql> desc select count(distinct a) from test.t;

ai/guides/image-search.md

@@ -36,7 +36,7 @@ image_embed = EmbeddingFunction(
 
 ### ステップ2. テーブルとベクトルフィールドを作成する {#step-2-create-a-table-and-vector-field}
 
-`VectorField()`画像の埋め込みを格納するためのベクトルフィールドを定義します。3 `source_field`画像のURLを格納するフィールドを指定するためのパラメータです。
+`VectorField()`画像の埋め込みを格納するためのベクトルフィールドを定義します。`source_field`画像のURLを格納するフィールドを指定するためのパラメータです。
 
 ```python
 from pytidb.schema import TableModel, Field

ai/guides/vector-search.md

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

ai/reference/vector-search-index.md

@@ -130,7 +130,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES;
 +---------------+------------+----------+-------------+---------------+-----------+----------+------------+---------------------+-------------------------+--------------------+------------------------+---------------+------------------+
 ```
 
--   インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。5 `ROWS_STABLE_NOT_INDEXED` 0になると、インデックス構築が完了します。
+-   インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。`ROWS_STABLE_NOT_INDEXED` 0になると、インデックス構築が完了します。
 
     参考までに、768次元の500MiBベクトルデータセットのインデックス作成には最大20分かかる場合があります。インデクサーは複数のテーブルに対して並列実行できます。現在、インデクサーの優先度や速度の調整はサポートされていません。
 
@@ -148,7 +148,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES;
 
 ## ベクトルインデックスが使用されているかどうかを確認する {#check-whether-the-vector-index-is-used}
 
-クエリがベクトルインデックスを使用しているかどうかを確認するには、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを使用します。9 `TableFullScan`キュータの`operator info`列に`annIndex:`表示されている場合、このテーブルスキャンはベクトルインデックスを使用していることを意味します。
+クエリがベクトルインデックスを使用しているかどうかを確認するには、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを使用します。`TableFullScan`キュータの`operator info`列に`annIndex:`表示されている場合、このテーブルスキャンはベクトルインデックスを使用していることを意味します。
 
 **例: ベクトルインデックスが使用される**
 

alert-rules.md

@@ -406,7 +406,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
 -   説明：
 
-    低速TiKVノードがあります。1 `raftstore.inspect-interval` TiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)参照してください。
+    低速TiKVノードがあります。`raftstore.inspect-interval` TiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)参照してください。
 
 -   解決：
 
@@ -555,7 +555,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
     1.  TiDB ログからスロー クエリ ログを確認し、クエリでインデックスまたは完全なテーブル スキャンが使用されているかどうか、または分析に必要かどうかを確認します。
     2.  ホットスポットがあるかどうかを確認します。
-    3.  コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。7 `over seek bound`あるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。
+    3.  コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。`over seek bound`あるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。
 
 #### `TiKV_raftstore_thread_cpu_seconds_total` {#tikv-raftstore-thread-cpu-seconds-total}
 
@@ -567,7 +567,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
     このルールは、 Raftstoreによる CPU 使用率を監視します。値が高い場合、 Raftstoreスレッドへの負荷が高いことを示します。
 
-    アラートしきい値は[`raftstore.store-pool-size`](/tikv-configuration-file.md#store-pool-size)値の 80% です。3 `raftstore.store-pool-size`デフォルトで 2 なので、アラートしきい値は 1.6 になります。
+    アラートしきい値は[`raftstore.store-pool-size`](/tikv-configuration-file.md#store-pool-size)値の 80% です。`raftstore.store-pool-size`デフォルトで 2 なので、アラートしきい値は 1.6 になります。
 
 -   解決：
 

auto-increment.md

@@ -27,7 +27,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。
 
 ## コンセプト {#concept}
 
-`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。2 `INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。
+`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。`INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。
 
 パフォーマンス上の理由から、各TiDBサーバーには、 `AUTO_INCREMENT`個の数値が一括で割り当てられます（デフォルトでは3万個）。つまり、 `AUTO_INCREMENT`数値は一意であることが保証されますが、 `INSERT`ステートメントに割り当てられる値は、TiDBサーバーごとに単調なものになります。
 

auto-random.md

@@ -177,7 +177,7 @@ TiDBインスタンスが1つの場合、ノードは明示的な挿入を処理
 ALTER TABLE t AUTO_RANDOM_BASE=0;
 ```
 
-このステートメントは適切な基数を自動的に決定します。1 `Can't reset AUTO_INCREMENT to 0 without FORCE option, using XXX instead`ような警告メッセージが表示されますが、基数は変更さ**れる**ため、この警告は無視しても問題ありません。
+このステートメントは適切な基数を自動的に決定します。`Can't reset AUTO_INCREMENT to 0 without FORCE option, using XXX instead`ような警告メッセージが表示されますが、基数は変更さ**れる**ため、この警告は無視しても問題ありません。
 
 > **注記：**
 >

benchmark/benchmark-tidb-using-ch.md

@@ -58,7 +58,7 @@ tiup bench ch -H 172.16.5.140 -P 4000 -D tpcc prepare
 
 ## TiFlashレプリカを作成する {#create-tiflash-replicas}
 
-TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複製しません。1 `tpcc`のTiFlashレプリカを作成するには、次の SQL 文を実行する必要があります。指定されたTiFlashレプリカが作成されると、TiKV は最新のデータをリアルタイムでTiFlashに自動的に複製します。次の例では、クラスターに 2 つのTiFlashノードをデプロイし、レプリカ数を 2 に設定しています。
+TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複製しません。`tpcc`のTiFlashレプリカを作成するには、次の SQL 文を実行する必要があります。指定されたTiFlashレプリカが作成されると、TiKV は最新のデータをリアルタイムでTiFlashに自動的に複製します。次の例では、クラスターに 2 つのTiFlashノードをデプロイし、レプリカ数を 2 に設定しています。
 
     ALTER DATABASE tpcc SET tiflash replica 2;
 
@@ -70,8 +70,8 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc';
 
 上記のステートメントの結果は次のようになります。
 
--   `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。2 `1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。
--   `PROGRESS`レプリケーションの進行状況を示します。値は`0`から`1`までです。6 `1` TiFlashレプリカのレプリケーションが完了したことを意味します。
+-   `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。
+-   `PROGRESS`レプリケーションの進行状況を示します。値は`0`から`1`までです。`1` TiFlashレプリカのレプリケーションが完了したことを意味します。
 
 ## 統計を収集する {#collect-statistics}
 

benchmark/benchmark-tidb-using-sysbench.md

@@ -75,7 +75,7 @@ report-interval=10
 db-driver=mysql
 ```
 
-上記のパラメータは、実際のニーズに合わせて調整できます。1 `TIDB_HOST` TiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`テストにおける同時接続数で、「8、16、32、64、128、256」の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。
+上記のパラメータは、実際のニーズに合わせて調整できます。`TIDB_HOST` TiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`テストにおける同時接続数で、「8、16、32、64、128、256」の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。
 
 サンプル**設定**ファイルとして以下を参照してください。
 

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がインデックスを追加する際、データのバックフィルフェーズによってクラスターの読み取りと書き込みに負荷がかかります。`ADD INDEX`のコマンドが送信され、 `write reorg`番目のフェーズが開始されたら、GrafanaダッシュボードでTiDBとTiKVの読み取りと書き込みのパフォーマンスメトリックとアプリケーションの応答時間を確認し、 `ADD INDEX`操作がクラスターに影響を与えているかどうかを確認することをお勧めします。
 
 ## DDL関連コマンド {#ddl-related-commands}
 

best-practices/high-concurrency-best-practices.md

@@ -60,7 +60,7 @@ CREATE TABLE IF NOT EXISTS TEST_HOTSPOT(
 )
 ```
 
-このテーブルは構造が単純です。主キーの`id`以外に、セカンダリインデックスは存在しません。このテーブルにデータを書き込むには、次のステートメントを実行してください。3 `id`乱数として離散的に生成されます。
+このテーブルは構造が単純です。主キーの`id`以外に、セカンダリインデックスは存在しません。このテーブルにデータを書き込むには、次のステートメントを実行してください。`id`乱数として離散的に生成されます。
 
 ```sql
 SET SESSION cte_max_recursion_depth = 1000000;
@@ -92,7 +92,7 @@ FROM
 
 ![QPS1](/media/best-practices/QPS1.png)
 
-クライアントは短時間で「集中的な」書き込みリクエストを開始し、TiDBは3K QPSの書き込みを受信しました。理論上、負荷は6つのTiKVノードに均等に分散されるはずです。しかし、各TiKVノードのCPU使用率から判断すると、負荷分散は不均一です。1 `tikv-3`ノードが書き込みのホットスポットとなっています。
+クライアントは短時間で「集中的な」書き込みリクエストを開始し、TiDBは3K QPSの書き込みを受信しました。理論上、負荷は6つのTiKVノードに均等に分散されるはずです。しかし、各TiKVノードのCPU使用率から判断すると、負荷分散は不均一です。`tikv-3`ノードが書き込みのホットスポットとなっています。
 
 ![QPS2](/media/best-practices/QPS2.png)
 
@@ -156,9 +156,9 @@ TiDBは汎用的な用途向けのデータベースであり、データ分布
 SPLIT TABLE TEST_HOTSPOT BETWEEN (0) AND (9223372036854775807) REGIONS 128;
 ```
 
-事前分割操作の後、 `SHOW TABLE test_hotspot REGIONS;`のステートメントを実行して、 リージョン scattering の状態を確認します。3 `SCATTERING`の列の値がすべて`0`であれば、スケジューリングは成功です。
+事前分割操作の後、 `SHOW TABLE test_hotspot REGIONS;`のステートメントを実行して、 リージョン scattering の状態を確認します。`SCATTERING`の列の値がすべて`0`であれば、スケジューリングは成功です。
 
-次のSQL文を使用して、リージョンリーダーの分布を確認することもできます。1 `table_name`実際のテーブル名に置き換えてください。
+次のSQL文を使用して、リージョンリーダーの分布を確認することもできます。`table_name`実際のテーブル名に置き換えてください。
 
 ```sql
 SELECT
@@ -196,7 +196,7 @@ ORDER BY
 
 このような状況でホットスポット問題を回避するには、テーブル作成時に`SHARD_ROW_ID_BITS`と`PRE_SPLIT_REGIONS`使用します。 `PRE_SPLIT_REGIONS`の詳細については、 [分割前のリージョン](/sql-statements/sql-statement-split-region.md#pre_split_regions)を参照してください。
 
-`SHARD_ROW_ID_BITS` 、 `_tidb_rowid`列に生成された行 ID をランダムに散布するために使用されます。4 `PRE_SPLIT_REGIONS` 、テーブルの作成後にリージョンを事前に分割するために使用されます。
+`SHARD_ROW_ID_BITS` 、 `_tidb_rowid`列に生成された行 ID をランダムに散布するために使用されます。`PRE_SPLIT_REGIONS` 、テーブルの作成後にリージョンを事前に分割するために使用されます。
 
 > **注記：**
 >