一般的に使用される mysql 最適化 SQL ステートメントのクエリ方法の概要

1. クエリを最適化するには、まず、where と order by に関係する列にインデックスを作成することを検討してください。

2. where 句で != または <> 演算子を使用しないようにしてください。そうしないと、エンジンはインデックスの使用を放棄し、テーブル全体のスキャンを実行します。

3. where 句内のフィールドの null 値判定を避けるようにしてください。そうしないと、エンジンはインデックスの使用を放棄し、次のようなテーブル全体のスキャンを実行します。

select id from t where num is null

num にデフォルト値 0 を設定できます。テーブルの num 列に null 値がないことを確認してから、次のようにクエリします。

select id from t where num=0

4. 条件を接続するために where 句で または を使用しないようにしてください。そうしないと、エンジンがインデックスの使用を放棄し、フル テーブル スキャン (例:

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

) 次のようなクエリを実行できます:

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

5. 次のクエリでもフル テーブル スキャンが行われます:

select id from t where name like '%abc%'

効率を向上させるために、全文検索を検討できます。 。

6.in と not in も注意して使用する必要があります。そうでないと、次のような完全なテーブル スキャンが発生します。

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

連続値の場合、 between を使用できる場合は、 in では使用しないでください:

select id from t where num between 1 and 3

7. where sub の場合、文内でパラメーターを使用すると、フルテーブルスキャンが発生します。 SQL は実行時にのみローカル変数を解決するため、オプティマイザは実行時までアクセス プランの選択を延期できません。選択はコンパイル時に行う必要があります。ただし、アクセス プランがコンパイル時に構築される場合、変数の値はまだ不明であり、インデックス選択の入力として使用できません。たとえば、次のステートメントは完全なテーブル スキャンを実行します:
select id from t where num=@num
クエリでインデックスを使用するように強制することができます:

select id from t with(index(索引名)) where num=@num

8 式操作を避けるようにしてください。これにより、エンジンはインデックスの使用を断念し、テーブル全体のスキャンを実行します。例:

select id from t where num/2=100

を

select id from t where num=100*2

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

select id from t where substring(name,1,3)='abc'--name以abc开头的id 
select id from t where datediff(day,createdate,'2005-11-30')=0--'2005-11-30'生成的id

を

select id from t where name like 'abc%' 
select id from t where createdate>=&#39;2005-11-30&#39; and createdate<&#39;2005-12-1&#39;

10 に変更する必要があります。where 句の「=」の左側で関数、算術演算、その他の式演算を実行しないでください。そうしないと、システムが実行できない可能性があります。インデックスを正しく使用してください。

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

12. 空のテーブル構造を生成するなど、無意味なクエリを作成しないでください:

select col1,col2 into #t from t where 1=0

このタイプのコードは結果セットを返しませんが、システム リソースを消費します:

に変更する必要があります。

create table #t(...)

13. 多くの場合、in の代わりに存在を使用することをお勧めします:

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

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

select num from a where exists(select 1 from b where num=a.num)

14. すべてのインデックスがクエリに有効であるわけではありません。SQL はデータに基づいてクエリを最適化します。テーブル内 はい、インデックス列に大量の重複データがある場合、SQL クエリはインデックスを使用しないことがあります。たとえば、テーブルに性別フィールドがあり、ほぼ半数が男性、半数が女性である場合、その場合、インデックスが性別に基づいて構築されたとしても、クエリの効率には影響しません。

15. インデックスは多いほど良いですが、インデックスは対応する選択の効率を向上させますが、挿入または更新中にインデックスが再構築される可能性があるため、注意が必要です。インデックスの構築方法はケースバイケースで検討されます。テーブルに 6 つを超えるインデックスを持たないことをお勧めします。多すぎる場合は、一般的に使用されない一部の列にインデックスを構築する必要があるかどうかを検討する必要があります。

16. クラスター化インデックス データ列の順序は、テーブル レコードの物理的な格納順序であるため、列の値が変更されると、その列の順序が調整されます。テーブル全体のレコードを作成すると、多くの時間がかかります。アプリケーション システムがクラスター化インデックスのデータ列を頻繁に更新する必要がある場合は、インデックスをクラスター化インデックスとして構築する必要があるかどうかを検討する必要があります。

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

18. char/nchar の代わりに varchar/nvarchar をできるだけ使用してください。第 1 に、可変長フィールドの記憶領域が小さいため、クエリの場合、比較的小さなフィールドでの検索効率が向上します。明らかに高いです。

19. select * from t をどこでも使用せず、「*」を特定のフィールド リストに置き換え、未使用のフィールドを返さないでください。

20. 一時テーブルの代わりにテーブル変数を使用してみてください。テーブル変数に大量のデータが含まれている場合は、インデックスが非常に制限される (主キー インデックスのみ) ことに注意してください。

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

以上が一般的に使用される mysql 最適化 SQL ステートメントのクエリ方法の概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。