diff --git a/encryption-at-rest.md b/encryption-at-rest.md index 6ce015367cea1..e0d7a596e98d8 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -242,7 +242,7 @@ path = "/path/to/key/file" 3b5896b5be691006e0f71c3040a29495ddcad20b14aff61806940ebd780d3c62 ``` -### マスターキーを回転させる {#rotate-the-master-key} +### マスターキーをローテーションする {#rotate-the-master-key} マスターキーをローテーションするには、設定で新しいマスターキーと古いマスターキーの両方を指定し、TiKVを再起動する必要があります。新しいマスターキーを指定するには`security.encryption.master-key`を使用し、古いマスターキーを指定するには`security.encryption.previous-master-key`を使用します。 `security.encryption.previous-master-key`の設定形式は`encryption.master-key`と同じです。再起動後、TiKVは新しいマスターキーと古いマスターキーの両方にアクセスする必要がありますが、TiKVが起動して実行されると、TiKVは新しいキーのみにアクセスする必要があります。それ以降は、設定ファイルに`encryption.previous-master-key`設定を残しておいても問題ありません。再起動後も、TiKVは新しいマスターキーを使用して既存のデータを復号化できなかった場合にのみ、古いキーを使用しようとします。 @@ -367,7 +367,7 @@ server_configs: 上記の設定項目の意味やキーファイルの内容形式は TiKV と同様です。 -### マスターキーを回転させる {#rotate-the-master-key} +### マスターキーをローテーションする {#rotate-the-master-key} TiFlashのマスターキーをローテーションするには、TiKV のマスターキーをローテーションする手順に従ってください。現在、 TiFlash はオンラインでのマスターキーのローテーションもサポートしていません。そのため、ローテーションを有効にするにはTiFlashを再起動する必要があります。オンラインクエリを処理している稼働中のTiFlashクラスターに対して、ローリング再起動を実行することをお勧めします。 @@ -410,7 +410,7 @@ TiFlashもv4.0.9で暗号化メタデータ操作を最適化しており、そ ## BR S3 サーバー側暗号化 {#br-s3-server-side-encryption} -BRを使用して S3 にバックアップする際に S3 サーバー側の暗号化を有効にするには、引数を`--s3.sse`渡し、値を "aws:kms" に設定します。S3 は暗号化に独自の KMS キーを使用します。例: +BRを使用して S3 にバックアップする際に S3 サーバー側の暗号化を有効にするには、 `--s3.sse`引数を渡し、値を "aws:kms" に設定します。S3 は暗号化に独自の KMS キーを使用します。例: ``` tiup br backup full --pd --storage "s3:///" --s3.sse aws:kms diff --git a/functions-and-operators/control-flow-functions.md b/functions-and-operators/control-flow-functions.md index cd592a701f754..a5b6717a021bb 100644 --- a/functions-and-operators/control-flow-functions.md +++ b/functions-and-operators/control-flow-functions.md @@ -14,7 +14,7 @@ TiDB は、MySQL 8.0 で利用可能な[制御フロー関数](https://dev.mysql | [`IFNULL()`](#ifnull) | null if/else 構文 | | [`NULLIF()`](#nullif) | expr1 = expr2の場合は`NULL`返す | -## 場合 {#case} +## CASE {#case} [`CASE`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#operator_case)演算子を使用すると、条件付きロジックを実行し、指定された条件に基づいてクエリ結果をカスタマイズできます。 @@ -54,7 +54,7 @@ SELECT n, CASE WHEN n MOD 2 THEN "odd" ELSE "even" END FROM d; 10 rows in set (0.00 sec) ``` -## もし（） {#if} +## IF() {#if} [`IF()`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_if)関数を使用すると、値または式が真かどうかに基づいてさまざまなアクションを実行できます。 diff --git a/functions-and-operators/information-functions.md b/functions-and-operators/information-functions.md index 04ea204ad325a..2c078bc563282 100644 --- a/functions-and-operators/information-functions.md +++ b/functions-and-operators/information-functions.md @@ -25,7 +25,7 @@ TiDB は、MySQL 8.0 で利用可能な[情報関数](https://dev.mysql.com/doc/ | [`USER()`](#user) | クライアントから提供されたユーザー名とホスト名を返します | | [`VERSION()`](#version) | MySQLサーバーのバージョンを示す文字列を返します | -### ベンチマーク（） {#benchmark} +### BENCHMARK() {#benchmark} `BENCHMARK()`関数は、指定された回数、指定された式を実行します。 @@ -53,7 +53,7 @@ SELECT BENCHMARK(5, SLEEP(2)); 1 row in set (10.00 sec) ``` -### 接続ID() {#connection_id} +### CONNECTION_ID() {#connection_id} @@ -84,7 +84,7 @@ SELECT CONNECTION_ID(); 1 row in set (0.00 sec) ``` -### 現在のロール() {#current_role} +### CURRENT_ROLE() {#current_role} @@ -111,7 +111,7 @@ SELECT CURRENT_ROLE(); 1 row in set (0.00 sec) ``` -### 現在のユーザー() {#current_user} +### CURRENT_USER() {#current_user} `CURRENT_USER()`関数は、現在のセッションで使用されているアカウントを返します。 @@ -128,7 +128,7 @@ SELECT CURRENT_USER(); 1 row in set (0.00 sec) ``` -### データベース() {#database} +### DATABASE() {#database} `DATABASE()`関数は、現在のセッションで使用されているデータベース スキーマを返します。 @@ -145,7 +145,7 @@ SELECT DATABASE(); 1 row in set (0.00 sec) ``` -### 見つかった行() {#found_rows} +### FOUND_ROWS() {#found_rows} `FOUND_ROWS()`関数は、最後に実行された`SELECT`ステートメントの結果セット内の行数を返します。 @@ -180,7 +180,7 @@ SELECT FOUND_ROWS(); > > クエリ修飾子`SQL_CALC_FOUND_ROWS`は、`LIMIT`句を考慮せずに結果セットの合計行数を計算しますが、[`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)が有効な場合にのみ使用できます。このクエリ修飾子は、MySQL 8.0.17 以降では非推奨です。代わりに`COUNT(*)`を使用することをお勧めします。 -### 最終挿入ID() {#last_insert_id} +### LAST_INSERT_ID() {#last_insert_id} `LAST_INSERT_ID()`関数は、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)列を含むテーブルに最後に挿入された行の ID を返します。 @@ -241,11 +241,11 @@ SELECT ROW_COUNT(); 1 row in set (0.00 sec) ``` -### スキーマ() {#schema} +### SCHEMA() {#schema} `SCHEMA()`関数は[`DATABASE()`](#database)の同義語です。 -### セッションユーザー() {#session_user} +### SESSION_USER() {#session_user} `SESSION_USER()`関数は[`USER()`](#user)の同義語です。 @@ -253,7 +253,7 @@ SELECT ROW_COUNT(); `SYSTEM_USER()`関数は[`USER()`](#user)の同義語です。 -### ユーザー（） {#user} +### USER() {#user} `USER()`関数は現在の接続のユーザーを返します。`USER()`はワイルドカードではなく実際のIPアドレスを表示するため、 `CURRENT_USER()`の出力とは若干異なる場合があります。 @@ -270,7 +270,7 @@ SELECT USER(), CURRENT_USER(); 1 row in set (0.00 sec) ``` -### バージョン() {#version} +### VERSION() {#version} `VERSION()`関数は、MySQLと互換性のある形式でTiDBのバージョンを返します。より詳細な結果を取得するには、 [`TIDB_VERSION()`](/functions-and-operators/tidb-functions.md#tidb_version)関数を使用します。 diff --git a/functions-and-operators/miscellaneous-functions.md b/functions-and-operators/miscellaneous-functions.md index 3ee86bd2ddc8e..5150160d8f33f 100644 --- a/functions-and-operators/miscellaneous-functions.md +++ b/functions-and-operators/miscellaneous-functions.md @@ -30,7 +30,7 @@ TiDB は、MySQL 8.0 で利用可能な[その他の関数](https://dev.mysql.co | [`UUID_TO_BIN()`](#uuid_to_bin) | UUIDをテキスト形式からバイナリ形式に変換する | | [`VALUES()`](#values) | INSERT時に使用される値を定義します | -### 任意の値() {#any_value} +### ANY_VALUE() {#any_value} `ANY_VALUE()`関数は、値のグループから任意の値を返します。通常、 `SELECT`ステートメントに集計されていない列を`GROUP BY`句とともに含める必要があるシナリオで使用されます。 @@ -113,7 +113,7 @@ SELECT BIN_TO_UUID(0x11EEEB6D9A17B457BACF5405DB7AAD56, 1); [UUID()](#uuid)および[UUIDのベストプラクティス](/best-practices/uuid.md)も参照してください。 -### デフォルト（） {#default} +### DEFAULT() {#default} `DEFAULT()`関数は、列のデフォルト値を取得するために使用されます。 @@ -139,7 +139,7 @@ TABLE t1; 前述の例では、 `UPDATE`ステートメントは`c1`列の値を、列のデフォルト値 ( `5` ) に`3`を加えた値に設定し、結果として`8`という新しい値になります。 -### グループ化() {#grouping} +### GROUPING() {#grouping} [`GROUP BY`修飾子](/functions-and-operators/group-by-modifier.md)を参照してください。 @@ -258,7 +258,7 @@ SELECT IS_IPV4_COMPAT(INET6_ATON('::127.0.0.1')); 1 row in set (0.00 sec) ``` -### IS_IPV4_MAPPE() {#is_ipv4_mapped} +### IS_IPV4_MAPPED() {#is_ipv4_mapped} `IS_IPV4_MAPPED()`関数は、指定された引数が IPv4 マップド アドレスであるかどうかをテストします。 @@ -343,7 +343,7 @@ SELECT 'value' AS 'column name' UNION ALL SELECT 'another value'; 2 rows in set (0.00 sec) ``` -### 寝る（） {#sleep} +### SLEEP() {#sleep} `SLEEP()`関数は、クエリの実行を指定された秒数だけ一時停止するために使用されます。 @@ -379,11 +379,11 @@ SELECT UUID(); [UUIDのベストプラクティス](/best-practices/uuid.md)も参照してください。 -### UUIDからビンへ {#uuid_to_bin} +### UUID_TO_BIN {#uuid_to_bin} [BIN_TO_UUID()](#bin_to_uuid)を参照してください。 -### 値() {#values} +### VALUES() {#values} `VALUES(col_name)`関数は、 [`INSERT`](/sql-statements/sql-statement-insert.md)ステートメントの`ON DUPLICATE KEY UPDATE`句で特定の列の値を参照するために使用されます。 diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index 90640b59cc3e3..7250ffdc7f6a1 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -1698,7 +1698,7 @@ FROM 4 rows in set (0.00 sec) ``` -次の例は、 `REGEXP` `SELECT`句に限定されないことを示しています。例えば、クエリの`WHERE`句でも使用できます。 +次の例は、 `REGEXP`が`SELECT`句に限定されないことを示しています。例えば、クエリの`WHERE`句でも使用できます。 ```sql SELECT @@ -2071,7 +2071,7 @@ SELECT n, REPEAT('x',n) FROM nr; 20 rows in set (0.01 sec) ``` -次の例は、 `REPEAT()`複数の文字で構成される文字列に対して操作できることを示しています。 +次の例は、 `REPEAT()`が複数の文字で構成される文字列に対して操作できることを示しています。 ```sql SELECT REPEAT('ha',3); diff --git a/partitioned-table.md b/partitioned-table.md index 7bfd653355975..4efd22b9d5bf6 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -1108,9 +1108,9 @@ ALTER TABLE example TRUNCATE PARTITION p0; Query OK, 0 rows affected (0.03 sec) ``` -### パーティションテーブルをパーティションテーブルに変換する {#convert-a-partitioned-table-to-a-non-partitioned-table} +### パーティションテーブルを非パーティションテーブルに変換する {#convert-a-partitioned-table-to-a-non-partitioned-table} -パーティションテーブルをパーティションテーブルに変換するには、次のステートメントを使用できます。このステートメントは、パーティション化を削除し、テーブルのすべての行をコピーし、テーブルのインデックスをオンラインで再作成します。 +パーティションテーブルを非パーティションテーブルに変換するには、次のステートメントを使用できます。このステートメントは、パーティション化を削除し、テーブルのすべての行をコピーし、テーブルのインデックスをオンラインで再作成します。 ```sql ALTER TABLE REMOVE PARTITIONING @@ -1753,7 +1753,7 @@ show stats_meta where table_name like "t"; 3 rows in set (0.01 sec) ``` -グローバルな`dynamic`プルーニングモードを有効にした後、SQLステートメントで使用される統計情報が正しいことを確認するには、テーブルまたはテーブルのパーティションで`analyze`手動でトリガーして、グローバル統計情報を取得する必要があります。 +グローバルな`dynamic`プルーニングモードを有効にした後、SQLステートメントで使用される統計情報が正しいことを確認するには、テーブルまたはテーブルのパーティションで`analyze`を手動でトリガーして、グローバル統計情報を取得する必要があります。 ```sql analyze table t partition p1; diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index 6411404a2bb7a..f35abde48ac73 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -145,7 +145,7 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 - QPS: Query Per Second（1秒あたりのクエリ数）の略。アプリケーションによって実行されたSQL文の数を示します。 - CPSタイプ別：Command Per Secondの略。コマンドはMySQLプロトコル固有のコマンドを示します。クエリ文は、クエリコマンドまたはプリペアドステートメントのいずれかによってTiDBに送信できます。 -- プラン キャッシュ OPS を使用するクエリ: `avg-hit` 、TiDB クラスターで 1 秒あたりに実行計画 キャッシュを使用するクエリの数であり、 `avg-miss` 、TiDB クラスターで 1 秒あたりに実行計画 キャッシュを使用しないクエリの数です。 +- Queries Using Plan Cache OPS: `avg-hit` 、TiDB クラスターで 1 秒あたりに実行計画 キャッシュを使用するクエリの数であり、 `avg-miss` 、TiDB クラスターで 1 秒あたりに実行計画 キャッシュを使用しないクエリの数です。 `avg-hit + avg-miss`は`StmtExecute`に等しく、これは1秒あたりに実行される全クエリ数です。TiDBでプリペアドプランキャッシュを有効にすると、以下の3つのシナリオが発生します。 @@ -170,14 +170,14 @@ TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。 - QPSパネルの赤い太線は失敗したクエリを表し、右側のY軸は失敗したクエリの数を示しています。0以外の値は、失敗したクエリが存在することを意味します。 - 合計 QPS は、CPS By Type パネルのクエリの数と等しく、クエリ コマンドがアプリケーションによって使用されています。 -- プランキャッシュを使用するクエリOPSパネルにはデータが表示されません。これは、クエリコマンドでプリペアドプランキャッシュが利用できないためです。つまり、TiDBはクエリ実行ごとに実行計画を解析して生成する必要があります。その結果、TiDBによるCPU消費量の増加に伴い、コンパイル時間が長くなります。 +- Queries Using Plan Cache OPSパネルにはデータが表示されません。これは、クエリコマンドでプリペアドプランキャッシュが利用できないためです。つまり、TiDBはクエリ実行ごとに実行計画を解析して生成する必要があります。その結果、TiDBによるCPU消費量の増加に伴い、コンパイル時間が長くなります。 **例3: OLTPワークロードに対してプリペアドステートメントが有効になっている場合、プリペアドプランキャッシュは利用できません** `StmtPrepare`回 = `StmtExecute`回 = `StmtClose`回 ~= `StmtFetch`回。アプリケーションは準備 > 実行 > フェッチ > クローズのループを使用します。プリペアドステートメントオブジェクトのリークを防ぐため、多くのアプリケーションフレームワークは`execute`フェーズの後に`close`を呼び出します。これにより、2つの問題が発生します。 - SQL 実行には 4 つのコマンドと 4 回のネットワーク ラウンドトリップが必要です。 -- プランキャッシュを使用するクエリのOPSは0で、プリペアドプランキャッシュのヒットがゼロであることを示しています。`StmtClose`のコマンドはデフォルトでキャッシュされた実行計画をクリアし、次の`StmtPrepare`コマンドで実行計画を再度生成する必要があります。 +- Queries Using Plan Cache OPSは0で、プリペアドプランキャッシュのヒットがゼロであることを示しています。`StmtClose`のコマンドはデフォルトでキャッシュされた実行計画をクリアし、次の`StmtPrepare`コマンドで実行計画を再度生成する必要があります。 > **Note:** > @@ -193,7 +193,7 @@ TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。 - QPSパネルでは、赤い太線が失敗したクエリの数を示し、右側のY軸がその数値の座標値を示しています。この例では、1秒あたりの失敗したクエリの数は74.6です。 - CPS By Type パネルでは、1 秒あたり`StmtPrepare`コマンドの数が 1 秒あたり`StmtClose`コマンドの数よりはるかに多く、プリペアドステートメントのアプリケーションでオブジェクト リークが発生していることを示しています。 -- プラン キャッシュを使用したクエリ OPS パネルでは、 `avg-miss`タイプ別 CPS パネルの`StmtExecute`とほぼ等しく、ほとんどすべての SQL 実行で実行計画 キャッシュが失われていることを示しています。 +- Queries Using Plan Cache OPS パネルでは、 `avg-miss`がタイプ別 CPS パネルの`StmtExecute`とほぼ等しく、ほとんどすべての SQL 実行で実行計画 キャッシュが失われていることを示しています。 #### KV/TSO 要求 OPS とソース別の KV 要求時間 {#kv-tso-request-ops-and-kv-request-time-by-source} diff --git a/performance-tuning-overview.md b/performance-tuning-overview.md index 226b360559c67..86dcca0f8bb43 100644 --- a/performance-tuning-overview.md +++ b/performance-tuning-overview.md @@ -41,7 +41,7 @@ summary: このドキュメントでは、ユーザー応答時間、スルー ユーザー応答時間は、サービス時間、キュー時間、およびユーザー要求を完了するための同時待機時間で構成されます。 ``` -User Response time = Service time + Queuing delay + Coherency delay +ユーザー応答時間 = サービス時間 + キュー時間 + 同時待機時間 ``` - サービス時間: リクエストを処理するときにシステムが特定のリソースに消費する時間。たとえば、データベースが SQL リクエストを完了するために消費する CPU 時間など。