sql >> データベース >  >> RDS >> Sqlserver

データベースの速度を大幅に低下させている6つの問題クエリ

    データベースのパフォーマンスの低下は、すべてのDBAの側で厄介です。また、パフォーマンスの問題の根本的な原因を特定することは必ずしも容易ではなく、ストレスを増大させるだけです。

    SQL Serverデータベースの調整は、パフォーマンスの問題の一部を解決するための優れた方法ですが、最適化プロセスをどこから開始すべきかが常に明確であるとは限りません。ディスク容量、メモリ、その他のネットワークおよびハードウェアのパフォーマンスキラーを除外しても、SQL Serverのパフォーマンスがまだ遅れている場合は、クエリを掘り下げてみましょう。

    最適化されていないクエリは、システムに無数のパフォーマンスの問題を引き起こす可能性があります。明るい面として、いくつかの一般的なクエリの間違いが、データベースのパフォーマンス低下の大部分の原因となっています。

    クエリでこれらの6つの問題のいずれかに悩まされている場合は、深刻なパフォーマンス調整の準備をしてください。

    問題クエリ1:先頭にワイルドカードが付いた式のように

    主要なワイルドカードは、MySQLがインデックスを利用しないようにし、テーブル内のフィールドにインデックスを付けた場合でも、全表スキャンを強制します。テーブル内のすべての行をスキャンすると、クエリ結果の配信が大幅に遅くなるため、先頭のワイルドカードを削除して効率を向上させます。

    問題クエリ2:「Where」および「GroupBy」句で使用されるインデックス付けされていない列

    列にインデックスを付けると、全表スキャンが不要になるため、クエリ結果をより速く返すことができます。インデックス付けは、レコードが返されたときにレコードを並べ替えるのにも役立ち、それらのレコードが一意に識別できることを保証します。これは、10行を超えるテーブルで特に役立ちます。

    少し見方をすれば、インデックス作成の前後にクエリ分析で「explain」ステートメントを実行することを検討してください。これにより、自分で保存したスキャンの行数がわかります。

    問題クエリ3:ユニオン句の代わりに「or」演算子を使用するステートメントのように

    テーブルのフィールドまたは列に対して比較演算子「or」を使用してクエリを実行すると便利な場合がありますが、「where」句に「or」を頻繁に適用することは、全表スキャンのもう1つのファストトラックです。

    union句を使用すると、SQLクエリの実行を高速化できます。特に、クエリの両側で異なるインデックスが最適化されている場合はそうです。基本的に、ユニオンオペレーターは、2つの高速なインデックス付きクエリの結果を取得し、それらを1つにマージします。

    問題クエリ4:ワイルドカード検索

    ワイルドカードを使用して検索する必要があるが、パフォーマンスを低下させたくないという状況で立ち往生している場合は、MySQL全文検索を使用してみてください。全文検索はワイルドカード文字を使用した検索よりもかなり高速であり、巨大なデータベースを検索するときに、より関連性の高い結果が得られるという追加の利点があります。

    問題クエリNo.5:最適化されていないデータベーススキーマ

    データベーススキーマも最適化しない場合にのみ、SQLクエリのパフォーマンスを大幅に向上させることができます。改善のためのヒントをいくつか紹介します。

    テーブルの正規化

    データの冗長性はパフォーマンスを低下させるため、データベースでファクトを1回だけ表すようにしてください。たとえば、複数のテーブルで顧客を参照する場合は、「customer_name」を1回だけ使用し、その後の参照には「customer_ID」を使用します。

    最適なデータ型を使用する

    データ型に関して覚えておくべきいくつかの重要なポイント:

    • テーブルを設計するときは短い方が良いです。たとえば、ユーザー数が100未満のシステムユーザーテーブルの「user_id」フィールドには「TINYINT」データ型を使用します。
    • フィールドで日付値が必要な場合は「date_time」データ型を使用するため、事後にレコードを日付形式に変換する必要はありません。
    • MySQLは、varcharなどのテキストデータ型よりも整数値の方がうまく機能します。

    ヌル値を避ける

    列のnull値はクエリ結果に悪影響を与える可能性があるため、レコードが必須値を必要としないフィールドにデフォルト値を割り当てる必要がある場合があります。

    列を多すぎないようにしてください

    幅の広いテーブル(100列を超える)を処理するには、多くのCPUとリソースが必要です。どうしても幅の広いテーブルを含める必要がない限り、テーブルをより小さな論理テーブルに分割することをお勧めします。

    結合の最適化

    結合が多すぎる(およびテーブルが多すぎる)SQLステートメントは、パフォーマンスに悪影響を及ぼします。クエリごとに12を超えない結合を撮影します。

    問題クエリNo.6:キャッシュされていないMySQLクエリ

    多くの選択クエリを実行するWebサイトおよびアプリケーションは、MySQLクエリをキャッシュすることで恩恵を受けます。 MySQLクエリキャッシングは、選択クエリを結果のデータセットと一緒にキャッシュし、クエリが複数回実行された場合はメモリ(ディスクではなく)からフェッチするため、読み取り操作中のパフォーマンスを高速化します。

    SQL Serverデータベースの高可用性を維持し、エンドユーザーが満足できるようにするには、パフォーマンスの調整が不可欠です。ただし、残念ながら、チューニングが最も必要な場所がすぐにわかるとは限りません。パフォーマンスの問題で明らかなネットワークとハードウェアのソースを排除した場合は、クエリに焦点を移してください。

    DBAとして長い間働いている場合は、これらの問題クエリの1つ(またはすべて)に遭遇した可能性があります。何に注意すべきかがわかったので、パフォーマンス改善イニシアチブに積極的に取り組み、これらの一般的なクエリの問題点を修正して、SQLServerクエリ最適化のメリットを享受できるようにします。


    1. 配列タイプのarray_agg

    2. MySQLエラー::'ユーザー'root'@'localhost'のアクセスが拒否されました

    3. Windows732ビットへのOracle11gRelease 2EnterpriseEditionのインストール

    4. 来週のMicrosoftMVPサミット中にTwitterでフォローしてください