update MD by dispatch event pingcap/docs i18n-ja-release-8.1

markdown-pages/ja/tidb/release-8.1/TOC.md

@@ -137,7 +137,7 @@
     -   [インポートのベストプラクティス](/tidb-lightning/data-import-best-practices.md)
     -   移行シナリオ
         -   [Auroraからの移行](/migrate-aurora-to-tidb.md)
-        -   [MySQL から小さなデータセットを移行する](/migrate-small-mysql-to-tidb.md)
+        -   [MySQL から小規模データセットを移行する](/migrate-small-mysql-to-tidb.md)
         -   [MySQL から大規模なデータセットを移行する](/migrate-large-mysql-to-tidb.md)
         -   [小さなデータセットの MySQL シャードの移行とマージ](/migrate-small-mysql-shards-to-tidb.md)
         -   [大規模データセットの MySQL シャードの移行とマージ](/migrate-large-mysql-shards-to-tidb.md)
@@ -249,6 +249,7 @@
 -   性能チューニング
     -   チューニングガイド
         -   [性能チューニングの概要](/performance-tuning-overview.md)
+        -   [最適なパフォーマンスを得るための TiDB の設定](/tidb-performance-tuning-config.md)
         -   [パフォーマンス分析とチューニング](/performance-tuning-methods.md)
         -   [OLTP シナリオの性能チューニングプラクティス](/performance-tuning-practices.md)
         -   [TiFlashパフォーマンス分析方法](/tiflash-performance-tuning-methods.md)
@@ -330,7 +331,7 @@
         -   [PDスケジュール](/best-practices/pd-scheduling-best-practices.md)
         -   [大規模リージョンによる TiKV性能チューニング](/best-practices/massive-regions-best-practices.md)
         -   [3ノードのハイブリッド展開](/best-practices/three-nodes-hybrid-deployment.md)
-        -   [3 つのデータ センター展開でのローカル読み取り](/best-practices/three-dc-local-read.md)
+        -   [3 つのデータセンター展開におけるローカル読み取り](/best-practices/three-dc-local-read.md)
         -   [UUIDを使用する](/best-practices/uuid.md)
         -   [読み取り専用ストレージノード](/best-practices/readonly-nodes.md)
     -   [配置ルールを使用する](/configure-placement-rules.md)
@@ -488,7 +489,7 @@
             -   データソースの管理
                 -   [移行するMySQLインスタンスを切り替える](/dm/usage-scenario-master-slave-switch.md)
             -   タスクの管理
-                -   [失敗したDDLステートメントの処理](/dm/handle-failed-ddl-statements.md)
+                -   [失敗したDDL文の処理](/dm/handle-failed-ddl-statements.md)
                 -   [移行するテーブルのスキーマを管理する](/dm/dm-manage-schema.md)
             -   [クラスターのデータソースとタスク構成のエクスポートとインポート](/dm/dm-export-import-config.md)
             -   [アラートを処理する](/dm/dm-handle-alerts.md)

markdown-pages/ja/tidb/release-8.1/best-practices/tidb-best-practices.md

@@ -33,7 +33,7 @@ Raft は、強力な一貫性を備えたデータ複製を保証するコンセ
 
 ### 分散トランザクション {#distributed-transactions}
 
-TiDB は完全な分散トランザクションを提供し、モデルには[Google パーコレーター](https://research.google.com/pubs/pub36726.html)に基づいたいくつかの最適化が施されています。このドキュメントでは、次の機能を紹介します。
+TiDB は完全な分散トランザクションを提供し、モデルには[Google パーコレーター](https://research.google/pubs/large-scale-incremental-processing-using-distributed-transactions-and-notifications/)に基づいたいくつかの最適化が施されています。このドキュメントでは、次の機能を紹介します。
 
 -   楽観的取引モデル
 
@@ -107,13 +107,13 @@ TiDB は、グローバル インデックスでもある完全なセカンダ
 
     次の 2 つの条件では、2 つのアクセスの問題は発生しません。
 
-    -   インデックスの列はすでにクエリの要件を満たしています。 `t`テーブルの`c`列にインデックスがあり、クエリが`select c from t where c > 10;`であると仮定します。 このとき、インデックスにアクセスすると必要なデータがすべて取得されます。 この状況を`Covering Index`と呼びます。 ただし、クエリのパフォーマンスを重視する場合は、フィルターする必要はないがクエリ結果で返す必要がある列の一部をインデックスに入れて、複合インデックスを作成できます。 `select c1, c2 from t where c1 > 10;`例にとります。 複合インデックス`Index c12 (c1, c2)`を作成することで、このクエリを最適化できます。
+    -   インデックスの列はすでにクエリ要件を満たしています。 `t`テーブルの`c`列にインデックスがあり、クエリが`select c from t where c > 10;`であると仮定します。 このとき、インデックスにアクセスすると必要なデータがすべて取得されます。 この状況を`Covering Index`と呼びます。 ただし、クエリのパフォーマンスを重視する場合は、フィルターする必要はないがクエリ結果で返す必要がある列の一部をインデックスに入れて、複合インデックスを作成できます。 `select c1, c2 from t where c1 > 10;`例にとります。 複合インデックス`Index c12 (c1, c2)`を作成することで、このクエリを最適化できます。
 
     -   テーブルの主キーは整数です。この場合、TiDB は主キーの値を行 ID として使用します。したがって、クエリ条件が主キーにある場合は、行 ID の範囲を直接構築し、テーブル データをスキャンして結果を取得できます。
 
 -   クエリの同時実行
 
-    データは多くのリージョンに分散されるため、クエリは TiDB で同時に実行されます。ただし、大量のシステム リソースを消費する場合、デフォルトでは同時実行性は高くありません。また、OLTP クエリは通常、大量のデータを処理しないため、低い同時実行性で十分です。ただし、OLAP クエリの場合、同時実行性は高く、TiDB は次のシステム変数を通じてクエリの同時実行性を変更します。
+    データは多くのリージョンに分散されるため、クエリは TiDB で同時に実行されます。ただし、大量のシステム リソースを消費する場合、デフォルトでは同時実行性は高くありません。また、OLTP クエリには通常、大量のデータが含まれないため、低い同時実行性で十分です。ただし、OLAP クエリの場合、同時実行性は高く、TiDB は次のシステム変数を通じてクエリの同時実行性を変更します。
 
     -   [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) :
 
@@ -129,7 +129,7 @@ TiDB は、グローバル インデックスでもある完全なセカンダ
 
 -   インデックスを通じて結果の順序を確保する
 
-    インデックスを使用して、データをフィルタリングまたは並べ替えることができます。まず、インデックスの順序に従って行 ID を取得します。次に、行 ID の戻り順序に従って行の内容を返します。このように、返される結果はインデックス列に従って順序付けられます。インデックスをスキャンして行を取得するモデルは並列 + パイプラインであることは前に説明しました。行がインデックスの順序に従って返される場合、2 つのクエリ間の同時実行性が高くても、レイテンシーは短縮されません。したがって、同時実行性はデフォルトで低くなっていますが、 [`tidb_index_serial_scan_concurrency`](/system-variables.md#tidb_index_serial_scan_concurrency)変数を通じて変更できます。
+    インデックスを使用して、データをフィルタリングまたは並べ替えることができます。まず、インデックスの順序に従って行 ID を取得します。次に、行 ID の戻り順序に従って行の内容を返します。このようにして、返される結果はインデックス列に従って順序付けられます。インデックスをスキャンして行を取得するモデルは並列 + パイプラインであることは前に説明しました。行がインデックスの順序に従って返される場合、2 つのクエリ間の同時実行性が高くても、レイテンシーは短縮されません。したがって、同時実行性はデフォルトで低くなっていますが、 [`tidb_index_serial_scan_concurrency`](/system-variables.md#tidb_index_serial_scan_concurrency)変数を通じて変更できます。
 
 -   逆インデックススキャン
 
@@ -161,7 +161,7 @@ TiDB は、グローバル インデックスでもある完全なセカンダ
 
 大量のデータを削除する場合は、 `Delete from t where xx limit 5000;`使用することをお勧めします。ループを介して削除し、 `Affected Rows == 0`ループの終了条件として使用します。
 
-一度に削除する必要があるデータの量が多い場合、このループ メソッドは、削除ごとに逆方向に移動するため、どんどん遅くなります。前のデータを削除した後、多くの削除済みフラグが短期間残り (その後、ガベージ コレクションによってすべてがクリアされます)、次の`DELETE`ステートメントに影響します。可能であれば、 `WHERE`条件を絞り込むことをお勧めします`2017-05-26`のすべてのデータを削除する必要があると仮定すると、次のステートメントを使用できます。
+一度に削除する必要があるデータの量が多い場合、このループ メソッドは、各削除が後方に移動するにつれて速度がどんどん遅くなります。前のデータを削除した後、多くの削除済みフラグが短期間残り (その後、ガベージ コレクションによってすべてがクリアされます)、次の`DELETE`ステートメントに影響します。可能であれば、 `WHERE`条件を絞り込むことをお勧めします`2017-05-26`のすべてのデータを削除する必要があると仮定すると、次のステートメントを使用できます。
 
 ```sql
 for i from 0 to 23:

markdown-pages/ja/tidb/release-8.1/develop/dev-guide-proxysql-integration.md

@@ -328,7 +328,7 @@ systemctl start docker
     > 3.  TiDB Cloud Serverless クラスターをホストのリストに追加します。
     > 4.  ProxySQL とTiDB Cloud Serverless クラスター間の安全な接続を有効にします。
     >
-    > より深く理解するために、 `proxysql-prepare.sql`ファイルを確認することを強くお勧めします。ProxySQL 構成の詳細については、 [ProxySQL ドキュメント](https://proxysql.com/documentation/proxysql-configuration/)参照してください。
+    > 理解を深めるために、 `proxysql-prepare.sql`ファイルを確認することを強くお勧めします。ProxySQL 構成の詳細については、 [ProxySQL ドキュメント](https://proxysql.com/documentation/proxysql-configuration/)参照してください。
 
     以下は出力例です。出力にクラスターのホスト名が表示されています。これは、ProxySQL とTiDB Cloud Serverless クラスター間の接続が確立されていることを意味します。
 
@@ -620,7 +620,7 @@ systemctl start docker
 
 ## 生産環境 {#production-environment}
 
-本番環境では、完全に管理されたエクスペリエンスを実現するために[TiDB Cloud専用](https://www.pingcap.com/tidb-dedicated/)直接使用することをお勧めします。
+本番環境では、完全に管理されたエクスペリエンスを実現するために[TiDB Cloud専用](https://www.pingcap.com/tidb-cloud-dedicated/)直接使用することをお勧めします。
 
 ### 前提条件 {#prerequisite}
 
@@ -797,7 +797,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構
 >
 > 次の手順では、TiDB と ProxySQL のコンテナ イメージを使用してクエリ ルールを構成します。まだ取得していない場合は、詳細な手順については[統合セクション](#option-2-integrate-tidb-self-hosted-with-proxysql)参照してください。
 
-1.  TiDB および ProxySQL の[統合サンプルコードリポジトリ](https://github.com/pingcap-inc/tidb-proxysql-integration)クローンします。前の手順ですでにクローンしている場合は、この手順をスキップします。
+1.  TiDB および ProxySQL の[統合サンプルコードリポジトリ](https://github.com/pingcap-inc/tidb-proxysql-integration)クローンします。前の手順で既にクローンしている場合は、この手順をスキップします。
 
     <SimpleTab groupId="os">
 

markdown-pages/ja/tidb/release-8.1/mysql-compatibility.md

@@ -114,7 +114,7 @@ mysql> SELECT _tidb_rowid, id FROM t;
 3 rows in set (0.01 sec)
 ```
 
-ご覧のとおり、共有アロケータがあるため、 `id`毎回 2 ずつ増加します。この動作は[MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)では変わり、共有アロケータがないため、数字のスキップは行われません。
+示されているように、共有アロケータがあるため、 `id`毎回 2 ずつ増加します。この動作は[MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)では変わり、共有アロケータがないため、数字のスキップは行われません。
 
 <CustomContent platform="tidb">
 
@@ -136,13 +136,13 @@ mysql> SELECT _tidb_rowid, id FROM t;
 
 <CustomContent platform="tidb">
 
-TiDB は、パフォーマンス監視メトリックの保存とクエリに[プロメテウスとグラファナ](/tidb-monitoring-api.md)の組み合わせを利用します。TiDB では、パフォーマンス スキーマ テーブルは結果を返しません。
+TiDB は、パフォーマンス監視メトリックの保存とクエリに[プロメテウスとグラファナ](/tidb-monitoring-api.md)の組み合わせを利用します。TiDB では、ほとんどの場合、 [パフォーマンス スキーマ テーブル](/performance-schema/performance-schema.md)結果を返しません。
 
 </CustomContent>
 
 <CustomContent platform="tidb-cloud">
 
-TiDB Cloudでパフォーマンス メトリックを確認するには、 TiDB Cloudコンソールのクラスター概要ページを確認するか、 [サードパーティの監視統合](/tidb-cloud/third-party-monitoring-integrations.md)使用します。パフォーマンス スキーマ テーブルは TiDB で空の結果を返します。
+TiDB Cloudでパフォーマンス メトリックを確認するには、 TiDB Cloudコンソールのクラスター概要ページを確認するか、 [サードパーティの監視統合](/tidb-cloud/third-party-monitoring-integrations.md)使用します。ほとんどの場合、 [パフォーマンス スキーマ テーブル](/performance-schema/performance-schema.md) TiDB で空の結果を返します。
 
 </CustomContent>
 
@@ -171,7 +171,7 @@ TiDB では、サポートされているすべての DDL 変更をオンライ
 -   TiDB は、 `HASH` 、 `RANGE` 、 `LIST` 、および`KEY`のパーティション タイプをサポートします。サポートされていないパーティション タイプの場合、TiDB は`Warning: Unsupported partition type %s, treat as normal table`返します。ここで、 `%s`サポートされていない特定のパーティション タイプです。
 -   範囲、範囲列、リスト、およびリスト列でパーティション化されたテーブルは、 `ADD` 、 `DROP` 、 `TRUNCATE` 、および`REORGANIZE`操作をサポートします。その他のパーティション操作は無視されます。
 -   ハッシュおよびキーでパーティション化されたテーブルは、 `ADD` 、 `COALESCE` 、および`TRUNCATE`操作をサポートします。その他のパーティション操作は無視されます。
--   次の構文はパーティション テーブルではサポートされていません。
+-   パーティション テーブルでは次の構文はサポートされていません。
 
     -   `SUBPARTITION`
     -   `{CHECK|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD} PARTITION`