データベース SQL チューニングにはどのような方法がありますか?-mysql チュートリアル-php.cn

方法: 1. インデックスを作成するときは、テーブル全体のスキャンを避けるようにしてください。 2. インデックスでの計算の使用を避けてください。 3. パラメータ化された SQL を使用してみてください。 4. 複数の SQL ステートメントを 1 つの SQL に圧縮してみてください。 ; 5. HAVING 句を where 句に置き換えます; 6. 複数のテーブルを接続する場合は、テーブルの別名を使用します; 7. カーソルなどの使用を避けるようにしてください。

データベース SQL チューニングにはどのような方法がありますか?

このチュートリアルの動作環境: Windows7 システム、mysql8 バージョン、Dell G3 コンピューター。

1. インデックスを作成します

1. テーブル全体のスキャンを回避するには、まず where に関係する列にインデックスを作成し、

# で並べ替えることを検討する必要があります。 # #2. (1) 頻繁に取得する必要があるフィールドにインデックスを作成します。たとえば、テーブルフィールドのユーザー名に基づいて取得する場合は、名前フィールドにインデックスを作成する必要があります。従業員の部門と従業員の職位レベルに基づいて取得する場合、従業員の部門と従業員の職位レベルの 2 つのフィールドにインデックスを作成する必要があります。

(2) インデックスを作成すると検索のパフォーマンスが大幅に向上することが多いため、検索速度が遅すぎると感じた場合は、最初にインデックスを作成することを考えるべきです。

(3) 1 つのテーブルに 6 つを超えるインデックスを持たないことが最善です。多すぎる場合は、一般的に使用されない一部の列にインデックスを構築する必要があるかどうかを検討する必要があります。インデックスは多いほど良いです。インデックスにより、対応する選択の効率は向上しますが、挿入または更新中にインデックスが再構築される可能性があるため、挿入と更新の効率も低下します。そのため、インデックスの構築方法には注意が必要です。特定の状況に応じて考慮されます。

2. インデックスでの計算の使用を避ける

where 句で、インデックス列が計算または関数の一部である場合、DBMS オプティマイザーはインデックスを使用しません。フルテーブルクエリを使用する場合、この関数は一種の計算です。通常、EXISTS は in で使用され、in はインデックスを使用しないため、existing が使用されます。

低効率:

 select * from user where salary*22>11000(salary是索引列)

ログイン後にコピー

高効率:

 select * from user where salary>11000/22(salary是索引列)

ログイン後にコピー

3. プリコンパイルされたクエリを使用する

プログラムは通常、ユーザー入力に基づいて SQL を動的に実行します。このとき、パラメータ化された SQL をできる限り使用する必要があります。これにより、SQL インジェクションの脆弱性攻撃を回避できるだけでなく、重要なデータベースはこれらのパラメータ化された SQL をプリコンパイルします。これにより、DBMS は初めて実行されるときにクエリを最適化し、SQL ステートメントのプリコンパイルを実行します。これにより、今後 SQL が実行されるときに、プリコンパイルされた SQL ステートメントが結果が直接使用されるため、実行速度が大幅に向上します。

4. 複数の SQL ステートメントを 1 つの SQL ステートメントに圧縮してみてください

SQL を実行するたびに、ネットワーク接続を確立し、権限の検証を実行し、SQL ステートメントのクエリを最適化し、実行結果: このプロセスは非常に時間がかかるため、あまり多くの SQL ステートメントを実行しないようにしてください。1 つの SQL ステートメントに圧縮できる場合は、複数のステートメントを使用して実行しないでください。

5. HAVING 句を where 句に置き換えます

HAVING 句はすべてのレコードを取得した後にのみ結果セットをフィルタリングするのに対し、where は集計の前に結果セットをフィルタリングするため、HAVING 句の使用は避けてください。レコードを選択します。where 句を使用してレコードの数を制限できれば、このオーバーヘッドを減らすことができます。 HAVING の条件は一般的に集計関数のフィルタリングに使用されますが、条件は where 句に記述する必要があります。

6. テーブルエイリアスの使用

SQL ステートメント内で複数のテーブルを接続する場合は、テーブルエイリアスを使用し、各列名にそのエイリアスを接頭辞として付けてください。これにより、解析時間が短縮され、列名の曖昧さによって引き起こされる構文エラーが削減されます。

7. Union を Union all に置き換えます

SQL ステートメントで 2 つのクエリ結果セットのユニオンが必要な場合、検索結果に重複レコードがない場合でも、ユニオンの 2 つの結果セットが一致する場合は、最終結果を出力する前にマージやソートも試行しますので、検索結果に重複レコードがないと判断できる場合はunion allを使用すると効率が良くなります。

8. 中間結果を一時的に保存するために「一時テーブル」の使用を検討してください

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

ただし、システムテーブルリソースの消費を減らすために、一時テーブルを頻繁に作成および削除することも避ける必要があります。

9. 必要な場合にのみトランザクション開始変換を使用する

SQL Server の SQL ステートメントはデフォルトでトランザクションであり、ステートメントの実行後にデフォルトでコミットされます。実際、これは begin tran の最小化された形式であり、begin tran が各ステートメントの先頭に暗黙的に示され、commit が最後に暗黙的に示されるのと同じです。

場合によっては、begin tran を明示的に宣言する必要があります。たとえば、「挿入、削除、および変更」操作を実行する場合、複数のテーブルを同時に変更する必要があります。複数のテーブルのすべての変更を行う必要があります。テーブルが成功したか、どのテーブルも成功しませんでした。 begin tran はそのような役割を果たし、複数の SQL ステートメントをまとめて実行し、最終的にそれらをまとめてコミットできます。利点はデータの一貫性が保証されていることですが、完璧なものはありません。 Begin tran によって支払われる代償として、送信前に、SQL ステートメントによってロックされているすべてのリソースは、コミットされるまで解放できなくなります。

Begin tran がトラップする SQL ステートメントが多すぎると、データベースのパフォーマンスが低下することがわかります。大規模なトランザクションがコミットされる前に、他のステートメントが必然的にブロックされ、その結果、大量のブロックが発生します。

Begin tran を使用する原則は、データの一貫性を確保することを前提として、begin tran によってトラップされる SQL ステートメントが少ないほど良いということです。場合によっては、トリガーを使用してデータを同期できますが、begin tran は必ずしも使用されるわけではありません。