ホームページ  >  記事  >  データベース  >  SQL ステートメントの効率に関する問題の概要

SQL ステートメントの効率に関する問題の概要

巴扎黑
巴扎黑オリジナル
2016-12-20 13:44:041087ブラウズ

1. SQL 最適化の原則:

1 回の操作で読み取る必要があるブロックの数を最小限に抑える、つまり、最短時間で最大のデータ スループットを達成します。
不正な SQL の調整は通常、次の点から開始できます:
不正な SQL を確認し、その記述方法に最適化内容が含まれているかどうかを検討します。
サブクエリを確認します。 SQL サブクエリが単純な接続方法を使用して書き換えられるかどうかを検討します。
最適化を確認します。インデックスの使用
データベースのオプティマイザを考慮してください

2. SELECT * FROM table ステートメントを避け、チェックするフィールドが明確であることを確認してください。

3. SQL ステートメントでは、where 条件によってフィルターされるデータベース レコードが多いほど、位置決めがより正確になるため、where 条件をより多く前方に移動する必要があります。

4. クエリを実行するときは、可能な限りインデックス カバレッジを使用します。つまり、複合インデックスは SELECT フィールドに確立され、クエリ中にインデックス スキャンのみが実行され、データ ブロックは読み取られません。

5. 条件を満たすレコードがあるかどうかを判断する場合は、SELECT COUNT (*) を使用せず、上位 1 ステートメントを選択することをお勧めします。

6. SQL ステートメントを記述するときに内部修飾の原則を使用し、クエリ条件を分解して分類し、

を使用して SQL ステートメントの最内層を制限して、データ処理量を削減します。

7. order by 節での式の使用は絶対に避けてください。

8. 関連テーブルからデータを読み取る必要がある場合、関連テーブルの数は通常 7 を超えてはなりません。

9. IN と OR は慎重に使用し、In コレクション内のデータの量に注意する必要があります。コレクション内のデータは 200 を超えないようにすることをお勧めします。

10. インデックスを効果的に使用できるように、< 、 > を > に置き換えます。

11. クエリを実行するときは、冗長な列や冗長な行などの冗長なデータの読み取りを減らすようにしてください。

12. たとえば、複合インデックスを構築する場合、列の順序は F1、F2、F3、

となり、これらのフィールドが where 句または order by 句に表示される順序になります。インデックスを作成するときのフィールドの順序と同じである必要があり、一貫性があり、最初の列が含まれている必要があります。 F1、F1、F2、または F1、F2、F3 のみにすることができます。それ以外の場合、インデックスは使用されません。

13. 複数のテーブルに関連するクエリを実行する場合、記述方法は次の原則に従う必要があります。これにより、インデックスが構築され、クエリの効率が向上します。

書式は以下の通りです

select sum(table1.je) from table1 table1, table2 table2,

table3 where (table1の等価条件(=))と(table1の不等価条件)

and (table2と表 1 の結合条件) と (表 2 の等価条件) と (表 2 の非等価条件) と (表 3 と表 2 の結合条件) と (表 3 の等価条件) と (表 3 の非等価条件) です。

注: 後続のテーブルの出現順序が複数テーブルのクエリ時の効率に及ぼす影響については、まだ研究されていません。

14. サブクエリの問題。結合またはビューを使用して実装できる関数の場合は、サブクエリを使用しないでください。

例:

customer_id が含まれる顧客から名前を選択します (money>1000 の注文から customer_id を選択します)。


は次のステートメントに置き換える必要があります: select name from customer

inner join order on customer.customer_id=order.customer_id

where order.money>100。

15. WHERE 句では、列に対する四則演算を避けます。

特に where 条件の左側では、列を処理するために演算や関数を使用することは固く禁止されています。

たとえば、場所によっては部分文字列を like に置き換えることができます。

16. ステートメントに not in (in) 操作がある場合、

はそれを not contains (exists) で書き換えることを検討する必要があります。最良の方法は、外部接続を使用して実装することです。一对17. 業務プロセスの処理は、原則として、案件の開始から終了までの間に完了することが望ましい。

18. あまりにも多くの列で列関数や order by、group by などを使用しないように注意し、disti ソフトウェア開発を使用する場合は注意してください。

19. Union の代わりに Union all を使用すると、データベースはユニオン操作を実行します

まず、ユニオンの両端でクエリを実行し、

それを一時テーブルに置きます。次に、それを並べ替えて重複レコードをフィルターします。

既知のビジネス ロジックによりクエリ A とクエリ B に重複レコードが存在しないと判断された場合、

はクエリの効率を向上させるために Union の代わりに Union All を使用する必要があります。


声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。