読者です 読者をやめる 読者になる 読者になる

kazu22002の技術覚書

技術屋として日々の内容を記録しているサイト。PHPやcordovaをやっています。

SQLのパフォーマンス改善 その2

前回の「SQLのパフォーマンス改善 その1」続きです。

スロークエリで表示されたあとに、indexが効いていない部分の改善をしました。

  • インデックスが効いていない箇所を探す
  • 件数が過剰ではないか
  • サブクエリ
  • 関数での計算
  • ソート
  • DISTINCT

件数が過剰ではないか

次にクエリの件数が多すぎる場合があるのも気をつけます。

必要がない件数を検索している場合は必要がないため、できるかぎり必要な分だけにします。

検索の条件を適切に設定します。

これはrowsの件数で多いところを気にしていると発見しやすいです。

サブクエリ

サブクエリは発見しやすいですね。サブクエリを探すだけ。

次に、サブクエリ部分を省いて検索がcostがへった場合にはその部分が原因です。

必要な場合には、対処ができませんが、意外に必要ない場合のほうが多いです。

サブクエリだけでも「explain」でコストを見てみるのもいいと思います。やることは同じことです。

ほかにもサブクエリの部分を改善する方法として

・バッチや登録時に登録作成できる内容であればカラムとして持つ
・テーブルを正規化しない

場合によりますので、やってるうちにどうすればいいかをわかればいいと思います。

とにかくやってみる。の精神で。

関数での計算

関数は結局計算をしているので、一件ずつ計算をしていますので重くなります。

対処としては、これもSELECTの時に計算をしないようにする。

・バッチや登録時に登録作成できる内容であればカラムとして持つ

たぶん登録より、検索することのほうが多いので、こういう対処が多いかと。

登録、更新自体はそれほどのコストにはならないです。その部分で重い場合は、ほかの原因がきっとあります。

ソート

ソートでもindexが効いてないと、全部並び替えるために処理を過剰になります。

indexをつけてみて変わるかどうかやってみます。

DISTINCT

必要ないなら使用しない。かな。

ほとんど使わなくてもいける。みたいな話はありますが、必要なときは必要ですので、適宜です。

kazu22002.hatenablog.com

あとはスロークエリがでなくなることを日々確認

スロークエリがでなくなったり、CPUが抑えられるようになれば成果がでてきた実感が持てます。

3、4か月ぐらいかけてなんとか安定させることができたと思うので、少し成長を実感しています。

最近はexplainでseqを見た後は、力技でSQLの一部分を消していく感じで原因を探していってます。

件数が多くない場合にはあまりやる機会はないかもしれないですが、サービスが拡大するうえで必要になる部分だと思うので、機会があれば参考にしていただければと思います。

PostgreSQL徹底入門 第3版

PostgreSQL徹底入門 第3版

広告を非表示にする