diff --git a/develop/dev-guide-index-best-practice.md b/develop/dev-guide-index-best-practice.md index 237033856b676..caf5ad63bc784 100644 --- a/develop/dev-guide-index-best-practice.md +++ b/develop/dev-guide-index-best-practice.md @@ -28,7 +28,7 @@ CREATE TABLE `books` ( ## インデックス作成のベストプラクティス {#best-practices-for-creating-indexes} -- 複数の列を含む結合インデックスを作成します。これは[カバーインデックスの最適化](/explain-indexes.md#indexreader)呼ばれる最適化です。**カバーインデックス最適化**により、TiDB はインデックス上で直接データをクエリできるようになり、パフォーマンスが向上します。 +- 複数の列を含む結合インデックスを作成します。これは[カバリングインデックスの最適化](/explain-indexes.md#indexreader)呼ばれる最適化です。**カバリングインデックス最適化**により、TiDB はインデックス上で直接データをクエリできるようになり、パフォーマンスが向上します。 - 頻繁にクエリを実行しない列には、セカンダリインデックスを作成しないでください。セカンダリインデックスはクエリの速度向上に役立ちますが、副作用もあることに注意してください。インデックスを追加するたびに、行を挿入する際にキーと値が1つずつ追加されます。インデックスの数が増えるほど、書き込み速度が低下し、消費する領域も増加します。さらに、インデックスが多すぎるとオプティマイザの実行時間に影響し、不適切なインデックスはオプティマイザに誤動作をさせる可能性があります。そのため、インデックスの数が増えても必ずしもパフォーマンスが向上するとは限りません。 diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index bb19a3490b725..4f7abaddbe2b6 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -112,7 +112,7 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; TiDB 実行プランの詳細については、 [TiDB クエリ実行プランの概要](/explain-overview.md)参照してください。 -### 解決策: カバーインデックスを使用する {#solution-use-covering-index} +### 解決策: カバリングインデックスを使用する {#solution-use-covering-index} インデックスが、SQL ステートメントによってクエリされるすべての列を含むカバーリング インデックスである場合は、インデックス データをスキャンするだけでクエリに十分です。 @@ -152,7 +152,7 @@ EXPLAIN SELECT title, price FROM books WHERE title = 'Marian Yost'; +---------------------------+---------+-----------+-------------------------------------+-------------------------------------------------------+ ``` -パフォーマンスを最適化するには、インデックス`title_idx`を削除し、新しいカバーインデックス`title_price_idx`を作成します。 +パフォーマンスを最適化するには、インデックス`title_idx`を削除し、新しいカバリングインデックス`title_price_idx`を作成します。 ```sql ALTER TABLE books DROP INDEX title_idx; diff --git a/develop/dev-guide-sql-development-specification.md b/develop/dev-guide-sql-development-specification.md index 7bbc85e85417d..de135a6850c87 100644 --- a/develop/dev-guide-sql-development-specification.md +++ b/develop/dev-guide-sql-development-specification.md @@ -15,8 +15,8 @@ aliases: ['/ja/tidb/stable/dev-guide-sql-development-specification/','/ja/tidbcl ## SELECT *の使用法 {#code-select-code-usage} -- 基本原則: クエリに`SELECT *`使用しないでください。 -- 詳細：必要に応じて適切な列を選択し、 `SELECT *`使用してすべてのフィールドを読み取ることは避けてください。このような操作はネットワーク帯域幅を消費するためです。カバーインデックスを効果的に活用するには、クエリ対象のフィールドをインデックスに追加することを検討してください。 +- 基本原則: クエリに`SELECT *`を使用しないでください。 +- 詳細：必要に応じて適切な列を選択し、 `SELECT *`を使用してすべてのフィールドを読み取ることは避けてください。このような操作はネットワーク帯域幅を消費するためです。カバリングインデックスを効果的に活用するには、クエリ対象のフィールドをインデックスに追加することを検討してください。 ## フィールドで関数を使用する {#use-functions-on-fields} diff --git a/explain-indexes.md b/explain-indexes.md index 7ec1a7286619c..93be03cb5dbb5 100644 --- a/explain-indexes.md +++ b/explain-indexes.md @@ -132,7 +132,7 @@ EXPLAIN SELECT * FROM t1 ORDER BY intkey DESC LIMIT 10; ## インデックスリーダー {#indexreader} -TiDBは*カバーインデックス最適化*をサポートしています。インデックスからすべての行を取得できる場合、TiDBは通常`IndexLookup`で必要な2番目のステップを省略します。次の2つの例を考えてみましょう。 +TiDBは*カバリングインデックス最適化*をサポートしています。インデックスからすべての行を取得できる場合、TiDBは通常`IndexLookup`で必要な2番目のステップを省略します。次の2つの例を考えてみましょう。 ```sql EXPLAIN SELECT * FROM t1 WHERE intkey = 123; diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 9e5140d35fe3f..32bc8213dfc47 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -141,7 +141,7 @@ PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql - [TiDBのインデックス戦略](#index-strategy-in-tidb) - [複合指数戦略ガイドライン](#composite-index-strategy-guidelines) - [インデックス作成のコスト](#the-cost-of-indexing) - - [カバーインデックスを使用したSQLチューニング](#sql-tuning-with-a-covering-index) + - [カバリングインデックスを使用したSQLチューニング](#sql-tuning-with-a-covering-index) - [ソートを含む複合インデックスを使用したSQLチューニング](#sql-tuning-with-a-composite-index-involving-sorting) - [効率的なフィルタリングとソートのための複合インデックスを使用したSQLチューニング](#sql-tuning-with-composite-indexes-for-efficient-filtering-and-sorting) - [TiFlashを使用する場合](#when-to-use-tiflash) @@ -573,7 +573,7 @@ TiDBのパフォーマンスを最適化するには、インデックスを効 - 日付時刻列の時間範囲条件 - `!=` `<>`の他の非`IS NOT NULL`の`NOT IN` -4. カバーインデックスを最大限に活用するには、 `SELECT`リストから列を追加するか、集計に使用します。 +4. カバリングインデックスを最大限に活用するには、 `SELECT`リストから列を追加するか、集計に使用します。 **特別な考慮: `IN`条件** @@ -607,7 +607,7 @@ TiDBのパフォーマンスを最適化するには、インデックスを効 - [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md)使用してインデックスの使用状況統計を定期的に確認します。 - インデックスを設計するときは、ワークロードの書き込み/読み取り比率を考慮してください。 -#### カバーインデックスを使用したSQLチューニング {#sql-tuning-with-a-covering-index} +#### カバリングインデックスを使用したSQLチューニング {#sql-tuning-with-a-covering-index} カバリングインデックスには、 `WHERE`と`SELECT`句で参照されるすべての列が含まれます。カバリングインデックスを使用すると、追加のインデックス参照が不要になり、クエリのパフォーマンスが大幅に向上します。 diff --git a/tidb-cloud/tidb-cloud-sql-tuning-overview.md b/tidb-cloud/tidb-cloud-sql-tuning-overview.md index 18963682c660d..d063ea65dc5bc 100644 --- a/tidb-cloud/tidb-cloud-sql-tuning-overview.md +++ b/tidb-cloud/tidb-cloud-sql-tuning-overview.md @@ -64,7 +64,7 @@ TiDBによって選択された実行プランが最適でない場合は、 EXP SQLクエリが遅くなる最も一般的な原因は、 `SELECT`ステートメントがフルテーブルスキャンを実行するか、不適切なインデックスを使用していることです。EXPLAINまたはEXPLAIN ANALYZEを使用してクエリの実行プランを表示し、実行が遅くなる原因を特定できます。最適化に使用できる[3つの方法](/develop/dev-guide-optimize-sql.md)あります。 - セカンダリインデックスを使用する -- カバーインデックスを使用する +- カバリングインデックスを使用する - プライマリーインデックスを使用する ### DMLのベストプラクティス {#dml-best-practices}