SQL 言語の最も優れた点の 1 つは、シンプルな構文のおかげで、コマンドを簡単に覚えて実行できることです。 2つのクエリは同じように見えても、計算時間の点では異なり、これが大きな違いとなります。

レポート作成や最新のデータを抽出するために本番データベースを使用している組織では、本番データベースのリソースに不必要な負担をかけないように、SQLクエリを最適化することがさらに重要です。

  • 関連するステークホルダーを認識していますか
  • クエリを開発する際には、関連するすべての個人やチームを巻き込むことが不可欠です。

  • Have you identified your requirements?
  • すべての要件が満たされていることを確認するためのベスト プラクティスは、5 つの質問セットに答えることです – Who? なぜ? 何を? いつ?

  • 識別された要件は、具体的でポイントを突いていますか?
  • プロダクション データベースは重要な役割を果たします。 曖昧な要件でデータベースに負担をかけることは、あまりにもリスクが大きいのです。 したがって、クエリを実行する前に、すべての要件が具体的であることを確認し、適切な関係者と話し合ってください

    Master the art of creating indexes properly

    SQL のパフォーマンス チューニングは、適切なインデックスを作成することで行うことができ、重要な時間帯にデータベースにすばやくアクセスできるようになります。 これは、データベース初心者の多くが失敗する分野の1つです。

    インデックスを全く作成しないと、クエリの実行が遅くなり、データベースに不必要な負荷をかけることになるからです。 一方、すべてのインデックスを作成すると、インサート トリガーが期待どおりに動作せず、データベースが非効率になります。

    SELECT* を使用しない

    SELECT* (select all) は、テーブルからすべてのデータを照会するための略語としてよく使用されます。

    ここでの最善の方法は、SELECT ステートメントでフィールドを定義し、最終目標を達成するために必要なデータのみを照会するようデータベースに指示することです。

    例を挙げて理解を深めましょう。

    このクエリは、ニーズに関係なく Users テーブルに保存されているすべてのデータを取得するため、非効率的な方法です。

    SELECT*
    FROM Users

    これは、必要な情報だけを取り出し、データベースに負担をかけないようにするための、より効率的なクエリ方法です。

    SELECT LastName, Address, Contact
    FROM Users

    Use temporary tables wisely

    テンポラリテーブルの使用は素晴らしいことですが、クエリの複雑さを飛躍的に増大させます。

    しかし、単一のクエリでは処理できないストアド プロシージャを処理する必要がある場合は、一時テーブルを仲介することで悩みを解決できます。

    COUNT()を使用しない

    開発者が特定のレコードが存在するかどうかを確認する一般的な方法の 1 つは、EXISTS() の代わりに COUNT() を使用することです。 COUNT()は、テーブル全体をスキャンし、条件を満たすすべてのクエリをカウントするため、非効率的です。 一方、EXISTS()は目的の結果を見つけたらすぐにループを終了するので、より効率的です。

    Avoid using wildcard characters at the beginning of LIKE pattern

    SQL クエリを微調整するためには、次のような方法で LIKE パターンを使用しないようにする必要があります。 システムはテーブルのフルスキャンを実行することから始まり、これが速度に悪影響を及ぼします。

    SELECT* FROM Customers WHERE address LIKE ‘bar%’;

    Avoid using SELECT DISTINCT

    SELECT DISTINCT を使用することで、簡単にクエリから重複を取り除くことができますが、この機能はかなりの処理能力を消費します。 また、このクエリは、クエリ内のすべてのフィールドをグループ化して個別の結果を表示します。

    クエリ内の重複レコードを避けるためのより良い方法は、より多くのフィールドを追加することです。 そうすれば、グループ化の必要がなくなり、取得されるレコードも正確になります。

    例えば、以下は非効率的な方法です:

    SELECT DISTINCT FirstName, LastName, State
    FROM Users

    そして、以下は効率的な方法です。

    SELECT FirstName, LastName, Contact, Address, State, Zip
    FROM Users

    Bonus tip: 一部のクエリをオフピークの時間帯に設定する

    本番用データベースを安全かつ健全に保つために、一部のクエリをオフピークの時間帯、理想的には同時ユーザー数が最も少ない時間帯に設定することを強くお勧めします。 したがって、夜中の3~5時が最適な時間帯となります。 のようなクエリを実行するのに最適な時間です。

    • ループステートメント
    • 100万レコード以上の大きなテーブルでのSELECT*の実行
    • ネストされたサブクエリ
    • ワイルドカード検索
    • CROSS JOIN
    • SELECT DISTINCT ステートメント

    まとめ

    SQL のパフォーマンス チューニングは、データベースを健全に保つために重要です。 しかし、達成するのは簡単なことではありません。 SQL クエリのパフォーマンスは、データベース モデルや取得する必要のある情報の種類など、さまざまな要因に左右されます。

    すぐに実行されるクエリをすべて記録し、最適なソリューションを提供することで、厄介な状況を回避することを強くお勧めします。 また、DBAとして、開発者にデータ駆動型のダッシュボードを提供し、必要な情報を得るためにクエリを実行する必要がないようにすることもできます。 ここに、データベースから直接データを取得するSQLダッシュボードを作成する方法についての素晴らしい記事があります。 どのようにしてSQLクエリを微調整していますか? お聞かせください。

    コメントを残す

    メールアドレスが公開されることはありません。 * が付いている欄は必須項目です