SQL Serverを使用している際、突然動作が重くなって困った経験がある方は少なくないでしょう。
このような事態が起こる背景には、いくつかの原因が考えられます。
本記事では、SQL Serverの処理が遅くなったときの主な原因と、改善方法を解説します。
SQL Serverを快適に使えるよう対処したいのであれば、ぜひ参考にしてください。
目次
SQL Serverのパフォーマンスが低下する原因
SQL Serverのパフォーマンスが低下して動作が重くなった場合、主な原因は4つ挙げられます。
以下で、詳しく解説します。
原因①統計情報が古くなっている
SQL Serverの統計情報が古く、最新のデータと異なっていると、効率的なクエリの実行計画は作成できません。
古い統計情報をもとに作成された、効率の悪い実行計画に沿ってSQL Serverがデータベースにアクセスしてしまうと、処理が遅くなります。
統計情報とは、データベースに保存されているデータにおいて、どの値がどのくらいの頻度で使われているかをまとめた情報のことです。
クエリを実行する際、SQL Serverはこの統計情報をもとに、データを早く検索できる方法を見極めたり、データの最適な結合順序を選んだりしています。
しかし、統計情報が最新のデータと異なる場合、SQL Serverが適切なデータを迅速に参照できない可能性があります。
結果、データベースにアクセスする時間が短縮されず、処理が重くなるというわけです。
原因②SELECT*を含むクエリを発行している
データベースからデータを抽出するには、SQL文の“SELECT”を使用してクエリを発行しなければなりません。
このとき“*（アスタリスク）”を使うと、データの抽出に時間がかかり、動作が重くなるおそれがあります。
SELECT文で*を含むクエリを発行すると、テーブルのすべての列のデータを取得可能です。
テーブルの数が少ない場合は、すべての列のデータを取得したとしても、そこまで時間はかからないでしょう。
しかし、テーブルの数が多くなるとデータの抽出にかかる時間も長くなるため、SQL Serverのパフォーマンスの低下につながります。
原因③ループ処理のなかで何度もデータベースにアクセスしている
ループ処理のなかで何度もデータベースにアクセスしていると、処理に膨大な時間がかかることがあります。
ループ処理とは、ある条件を満たしているあいだ、コンピューターに同じ処理を繰り返させることです。
SQL文を使用したクエリをループ処理に組み込むと、データベースへのアクセスも同様に繰り返され、毎回データが参照されます。
データを参照するには相応の時間がかかるため、データベースにアクセスする回数が増えるほど、処理にかかる時間も増えるというわけです。
原因④インデックスの断片化が起きている
インデックスの断片化が起こることも、動作が重くなる原因の一つです。
インデックスの断片化とは、本来であればまとめられたはずのデータが、複数のページに散らばってしまう現象のことです。
これは、もともとあったインデックスのデータが追加もしくは削除されたときにできる、不要な空白によって起こります。
不要な空白を詰めずにそのままにしておくと、余計なページがどんどん増え、複数のページをまたいでデータが散乱してしまうのです。
結果、必要なデータを抽出する際に参照すべきページの範囲が広くなり、SQL Serverにかかる負荷やクエリの実行時間が増える可能性があります。
SQL Serverのパフォーマンスを改善する方法
前項で説明した原因を踏まえ、具体的にどのように対処すれば、SQL Serverのパフォーマンスを改善できるのでしょうか。
ここでは、低下したSQL Serverの処理速度を改善する方法を説明しますので、ぜひ参考にしてください。
方法①統計情報を更新する
古い統計情報が原因でSQL Serverの処理が重い場合は、手動で統計情報を更新することで改善が見込めます。
どのデータを抽出しても動作が重いのであれば、データベースに保存されているすべての統計情報を更新しましょう。
特定のクエリでのみパフォーマンスが低下しているときは、該当のデータのみ統計情報を更新すると、対応する手間を削減できます。
なお、SQL Serverは、自動で統計情報を更新する機能も備えています。
この機能は、たとえば“データベースにある20％以上のデータに変動があった際”のように、特定の条件を満たしたときのみ有効です。
データ量が増えると自動更新の間隔も長くなるので、手動で統計情報を更新することを習慣づけるのが望ましいといえます。
方法②クエリを発行するSQL文を見直す
SQL文にSELECT*を含むクエリを発行している、あるいはループ処理にSQL文を組み込んでいるときは、SQL文の見直しもパフォーマンスの改善につながる可能性があります。
前述の通り、SELECT*は、データの抽出元であるテーブルのすべての列を取得するためのSQL文です。
列のデータをすべて使うときはSELECT*を用いるべきですが、限られた列のみ抽出すればよいときは、余計な負荷をかけてしまいます。
そのため、SQL文で列の範囲を指定して、余計な負荷をかけないようにする必要があるのです。
また、ループ処理にSQL文を組み込んでいるときは、SQL文を使用したクエリの回数を減らせるような工夫が大切です。
たとえば、外部結合とCASE文を活用したり、データをキャッシュしたりすることが挙げられます。
以上のような方法で、なるべくSQL Serverへの負荷がかからないSQL文に修正しましょう。
方法③インデックスを再構築する
インデックスの断片化が起きている場合は、インデックスを再構築し、クエリを発行した際に参照されるページ数を減らす必要があります。
SQL Serverでは“ALTER INDEX”というSQL文を用いると、インデックスを再構築できます。
これにより不要なページやオブジェクトの空白を減らせるため、参照されるページ数も削減可能です。
また、不要なページやオブジェクトの空白を減らすと、より効率的にクエリが実行される可能性も高まります。
結果、SQL Serverのパフォーマンスの向上が期待できます。
方法④クエリの実行計画を変更する
前述した3つの改善方法を実践してもなお、SQL Serverの動作が重い場合は、クエリの実行計画を手動で変更するのも一案です。
すでにお伝えしたように、SQL Serverはクエリを実行するたびに、統計情報をもとにした最適なクエリの実行計画を作成しています。
しかし、最適だと考えられるクエリの実行計画に変更したにもかかわらず、パフォーマンスが低下してしまうことがあります。
このような場合は、手動で変更前の実行計画に戻す方法が有効です。
クエリの実行計画を変更前と変更後で比較するときは、SQL Serverに備わっているクエリストアという機能を使用します。
クエリストアとは、実行したクエリや実行計画の履歴を確認できる機能のことです。
クエリの処理時間を、変更前と変更後で比較できるため、以前のほうが速かったかどうか判断できます。
手を尽くしてもSQL Serverの処理速度が回復しないのであれば、このような方法でクエリの処理時間を比較したうえで、手動で実行計画を変更するとよいでしょう。
SQL Serverのパフォーマンスが低下したときは複数の原因が考えられる
今回は、SQL Serverのパフォーマンスが低下する主な原因と、改善する方法を解説しました。
SQL Serverの処理が遅くなったときは、さまざまな原因が考えられます。
改善できる方法は原因ごとに異なるため、本記事を参考に、適切に対処するとよいでしょう。
SQL Serverの動作が重くなった原因を探るには、SQL Serverのパフォーマンスを数値で可視化することも大切です。
コーソルにて取り扱っている製品なら、SQL Serverの処理速度がどの程度まで低下しているのか、数値で確かめられます。
「動作が重いSQL Serverを、どうにかして改善したい」とお考えの方は、ぜひお問い合わせください。
