SQLステートメントを最適化するにはどうすればよいですか?

SQL ステートメントの最適化には次のような方法があります: 1. SQL ステートメントの形式を統一する; 2. クエリを最適化し、テーブル全体のスキャンを回避する; 3. SQL ステートメントは簡潔にする必要がある; 4. 中間データを一時的に保存するために「一時テーブル」の使用を検討する結果; 5. 大規模なトランザクション操作を避けるようにしてください; 6. クライアントに大量のデータを返さないようにしてください。以下の記事で詳しく紹介していますので、ご参考になれば幸いです。

開発プロジェクトの初期段階では、ビジネス データの量が比較的少なかったため、一部の SQL の実行効率がプログラムの実行効率に与える影響はそれほど大きくありませんでした。また、SQL がプログラムの実行効率にどの程度効率的であるかを判断することもできないため、SQL の特別な最適化が行われることはほとんどありません。 SQLの実行効率がプログラムの実行効率に与える影響は徐々に大きくなるため、SQLの最適化が必要になります。

# SQL ステートメントを最適化するためのいくつかの方法:

1. SQL ステートメントの形式を統一する

# #多くの人は次の 2 つの SQL ステートメントが同じであると考えていますが、データベース クエリ オプティマイザーはこれらが異なるものであると考えます。

#select * from Dual

select * From Dual

ケースが異なるだけですが、クエリ アナライザーこれらは 2 つの異なる SQL ステートメントであるとみなされ、2 回解析する必要があります。 2 つの実行プランを生成します。したがって、プログラマは、同じクエリ ステートメントがどこでも一貫していることを確認する必要があります。スペースが 1 つ多くても機能しません。

2. * より を使用し、「*」を特定のフィールド リストに置き換え、未使用のフィールドを返さないでください。

3. クエリを最適化するには、テーブル全体のスキャンを避けるようにしてください。

1) where および order by に関係する列にインデックスを作成することを検討する必要があります。

2) where 句内のフィールドで null 値の判断を行わないようにしてください。そうしないと、エンジンはインデックスの使用を断念し、次のようなテーブル全体のスキャンを実行します。 used on num デフォルト値 0 を設定し、テーブルの num 列に null 値がないことを確認してから、次のようにクエリを実行します:

select id from t where num is null

3)。!= または 4)条件を接続するために where 句内で または を使用しないようにしてください。そうしないと、エンジンがインデックスの使用をあきらめて、テーブル全体のスキャンを実行します。たとえば、

select id from t where num=0

は次のようにクエリできます:

select id from t where num=10 or num=20

5)。in と in は慎重に使用してください。そうしないと、次のような問題が発生します。

select id from t where num=10    
union all    
select id from t where num=20

のような完全なテーブル スキャン。連続値の場合は、次の場合は使用できません。

select id from t where num in(1,2,3)

6)、ファジー クエリのように適切に使用します。

場合によっては、

select id from t where num between 1 and 3

キーワード %yue% のようなファジー クエリを実行する必要があることがあります。「%」が yue の前に使用されているため、クエリはテーブル全体をスキャンする必要があります。必要な場合を除き、% を追加しないでください。キーワードの前に

7 を置き​​ます。where 句でフィールドを表現しないようにしてください。これにより、エンジンはインデックスの使用を断念し、テーブル全体のスキャンを実行します。例:

select * from contact where username like ‘%yue%’

を

select id from t where num/2=100

8 に変更する必要があります)、where 句内のフィールドに対して関数演算を実行しないようにする必要があります。これにより、エンジンがインデックスを作成し、テーブル全体のスキャンを実行します。例:

名前が abc で始まる ID をクエリする

select id from t where num=100*2

は、次のように変更する必要があります:

select id from t where substring(name,1,3)='abc'

4. in

# の代わりに、exists を使用します。

# #多くの場合、in の代わりにexists を使用するのが良い選択です。Exists は存在をチェックするだけであり、そのパフォーマンスは in よりもはるかに優れています。例:

select id from t where name like 'abc%'

次のステートメントに置き換えます:

select num from a where num in(select num from b)

5.長すぎる、冗長すぎる SQL ステートメントは作成せず、使用できる場合は簡潔にしてください。文を 2 つ使用しないでください

一般に、Select ステートメントの結果はサブセットとして使用され、そのサブセットからクエリが実行されます。この種のネストされたステートメントは比較的一般的です。しかし経験によれば、3 レベル以上のネストでは、クエリ オプティマイザーは簡単に間違った実行計画を与える可能性があります。唖然としたからだ。人工知能のようなものは最終的には人間の解像度に劣り、人間がめまいを感じれば、データベースもめまいを感じることは保証できます。 また、実行計画は再利用可能であり、SQL文が単純であればあるほど再利用できる可能性が高くなります。複雑な SQL ステートメントで 1 文字が変更されると、その文字を再解析する必要があり、大量のゴミがメモリに詰め込まれることになります。データベースがどれほど非効率になるかは考えられます。

6. 中間結果を一時的に保存する「一時テーブル」の使用を検討する

SQL ステートメントを簡素化する重要な方法は、一時テーブルを使用して中間結果を一時的に保存することです。ただし、一時テーブルの利点はこれらをはるかに超えています。一時結果は一時テーブルに一時的に保存され、後続のクエリは tempdb に保存されます。これにより、プログラム内のメイン テーブルの複数回のスキャンが回避され、 「共有ロック」はプログラム実行中に「更新ロック」をブロックし、ブロックを軽減し、同時実行パフォーマンスを向上させます。

7, インデックス フィールドを条件として使用する場合、インデックスが複合インデックスの場合、システムが確実にインデックスを使用するようにインデックスの最初のフィールドを条件として使用する必要があります。それ以外の場合、インデックスは使用されないため、フィールドの順序は可能な限りインデックスの順序と一致する必要があります。

8. 数値フィールドを使用するようにしてください。。フィールドに数値情報のみが含まれる場合は、文字フィールドとして設計しないようにしてください。これにより、クエリと接続のパフォーマンスが低下し、ストレージが増加します。オーバーヘッド。
これは、エンジンがクエリと接続を処理するときに文字列内の各文字を 1 つずつ比較し、数値型の場合は 1 回の比較だけで十分であるためです。

9. できる限り char ではなく varchar を使用してください なぜなら、第一に、可変長フィールドの記憶領域は小さく、記憶領域を節約できるからです。小さなフィールドの方が明らかに検索効率が高くなります。

10. システム テーブル リソースの消費を減らすために、一時テーブルの頻繁な作成と削除を避けてください。

11. カーソルは効率が悪いため、カーソルの使用は避けてください。カーソルで操作するデータが 10,000 行を超える場合は、データの書き換えを検討する必要があります。

12. 大規模なトランザクション操作を避け、システムの同時実行性を向上させるようにしてください。

13. クライアントに大量のデータを返さないようにしてください。データの量が大きすぎる場合は、対応する要件が妥当であるかどうかを検討する必要があります。 おすすめのビデオ チュートリアル: 「

MySQL チュートリアル

」 以上がこの記事の全内容です。皆様の学習にお役に立てれば幸いです。さらにエキサイティングなコンテンツについては、PHP 中国語 Web サイトの関連チュートリアルのコラムに注目してください。 ！ ！

以上がSQLステートメントを最適化するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。