SQL SELECT ステートメントのパフォーマンスを最適化するための 6 つの簡単なヒント

SELECT ステートメントのパフォーマンス チューニングは非常に時間のかかる作業になることがありますが、私の意見では、これはパレートの法則に従っています。おそらく 20% の労力で 80% のパフォーマンス向上が得られ、残りの 20% のパフォーマンス向上を達成するには 80% の時間がかかる可能性があります。金星で作業している場合を除き、地球では 1 日が 243 日に相当しますが、納期のせいで SQL クエリを調整する時間が不十分になる可能性が高くなります。

SQL ステートメントの作成と実行の長年の経験に基づいて、クエリのパフォーマンスを向上させるときに参照するチェックリストの開発を開始しました。クエリ プランニングを行ったり、使用しているデータベースのドキュメントを読んだりする前に参照しますが、ドキュメントは複雑になる場合があります。私のチェックリストは決して包括的でも科学的でもありません。どちらかというと控えめな計算ですが、これらの簡単な手順に従うことで、ほとんどの場合パフォーマンスが向上すると言えます。以下のチェックリスト。

インデックスを確認する

インデックスは、SQL ステートメントの WHERE および JOIN 部分で使用されるすべてのフィールドに追加する必要があります。この 3 分間の SQL パフォーマンス テストに参加してください。学年に関係なく、これらの結果と情報を必ずお読みください。

作業データセットのサイズを制限します

これらの SELECT ステートメントで使用されているテーブルをチェックして、フィルタリングに WHERE 句を適用できるかどうかを確認してください。典型的な例は、テーブルに数千行しかない場合に良好にパフォーマンスするクエリです。しかし、アプリケーションが成長するにつれて、クエリの速度が低下しました。解決策は、当月のデータを表示するようにクエリを制限するのと同じくらい簡単な場合があります。

クエリ ステートメントにサブクエリがある場合は、外側のステートメントではなく、サブクエリの内側のステートメントでフィルタリングを使用するように注意してください。

必要なフィールドのみを選択してください

通常、追加のフィールドにより、返されるデータのテクスチャが増加し、より多くのデータが SQL クライアントに返されます。また:

•レポート機能と分析機能を備えたアプリケーションを使用する場合、レポート ツールは受信したデータを詳細な形式で集計する必要があるため、レポートのパフォーマンスが低下することがあります。

• 場合によっては、クエリが十分に高速に実行される場合もありますが、大量の詳細データがネットワーク経由でレポート サーバーに送信されるため、問題はネットワーク関連の問題である可能性があります。

•列指向の DBMS を使用する場合、選択した列のみがディスクから読み取られます。クエリに含める列が少ないほど、IO オーバーヘッドが小さくなります。

不要なテーブルを削除する

不要なテーブルを削除する理由は、クエリステートメントの不要なフィールドを削除する理由と同じです。

SQL ステートメントの作成は、通常、SQL ステートメントの作成とテストという多数の反復プロセスを必要とするプロセスです。開発中にクエリにテーブルを追加することがありますが、これは SQL コードによって返されるデータに影響を与えない可能性があります。 SQL が正しく実行されると、多くの人がスクリプトを確認せず、返される最終データに何の影響も及ぼさないテーブルを削除していることがわかりました。不要なテーブルとの JOINS 操作を削除することで、データベースが実行する必要があるプロセスの数が大幅に削減されます。場合によっては、列の削除など、削減したデータがデータベースを通じて戻ってくることがあります。

外部結合クエリの削除

これは言うは易く行うは難しですが、テーブルの内容の変更がどの程度の影響を与えるかによって決まります。解決策の 1 つは、両方のテーブルの行にプレースホルダーを配置して、OUTER JOINS 操作を削除することです。次のテーブルがあるとします。これらのテーブルでは、OUTER JOINS を定義することですべてのデータが返されるようになります:

CUSTOMER_ID	CUSTOMER_NAME
1	John Doe
2	メリージェーン
3	ピーターパン
4	ジョーソープ

CUSTOMER_ID	Sales_PERSON
NULL	Newbee Smith
2	Oldie Jones
1	もう一つのオールディーズ
NULL	グリーンホーン

解決策は、customer テーブルの行にプレースホルダーを追加し、sales テーブルのすべての NULL 値をプレースホルダーに更新することです。

CUSTOMER_ID	CUSTOMER_NAME
0	顧客がいません
1	John Doe
2	メリージェーン
3	ピーターパン
4	ジョー・ソープ

CUSTOMER_ID	Sales_PERSON
0	新人スミス
2	オールディー・ジョーンズ
1	もう一つのオールディー
0	グリーンホーン

OUTER JOIN 操作への依存を取り除くだけでなく、顧客のいない営業担当者の表現方法も標準化します。他の開発者は、ISNULL(customer_id, “まだ顧客がいません”) などの追加のステートメントを記述する必要はありません。

JOIN 句と WHERE 句の計算フィールドを削除する

これは、テーブル スキーマを変更するためにどの程度の権限が必要かによっては、言うは易く行うは難しのもう 1 つのトリックです。結合ステートメントで使用される計算フィールドは、テーブル内に新しいフィールドとして作成できます。次の SQL ステートメントを考えます:

FROM sales a 
JOIN budget b ON    ((YEAR(a.sale_date)* 100) + MONTH(a.sale_date)) = b.budget_year_month

sales テーブルに年と月を使用する列を追加すると、パフォーマンスが向上します。更新された SQL ステートメントは次のようになります:

SELECT * FROM PRODUCTSFROM sales a 
JOIN budget b ON    a.sale_year_month = b.budget_year_month

概要

上記の提案は次の点に要約できます:

• インデックスを確認する

• 必要な最小限のデータセットで操作する

• 不要なフィールドを削除するおよびテーブル

•JOIN 句と WHERE 句の計算操作を削除します

これらの提案すべてで SQL クエリのパフォーマンスが向上しない場合、最後の提案は Venus に移行することです。 SQL ステートメントの調整に必要なのは 1 日だけです。

上記は、SQL SELECT ステートメントのパフォーマンスを最適化するための 6 つの簡単なヒントの内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。