Postgresの統計情報を活用しています。
機能追加でプログラムを作成しているのと同じくらいSQLとの戦いを日々しています。
SQLの書き方でどうすればコストを減らせるかとEXPLAINと戦うようになっていますが、数あるコードから探すのは大変です。
統計情報を活用しよう
SQLで重くなる原因は主にインデックスや条件の絞り込み不足、大量データあたりかと。
インデックスがちゃんと効いているかをシステム全体でみることが統計情報を使うと可能です。
稼動統計情報を活用しよう(2) — Let's Postgres
表スキャンがどれだけあるのか。
意図していない内容で表スキャンがあると一気にシステムを遅くしてしまいます。
主にDBサーバーの負荷が高くなるため、予期しない障害を招いてしまうこともあると思います。
表スキャン（シーケンシャルスキャン）
EXPLAINでどの場所で表スキャンが行われているかどうかを見ています。
EXPLAIN SELECT * FROM tenk1;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)
「Seq Scan」って部分がシーケンシャルスキャン
シーケンシャルスキャンは全部を順に読んでいくものなので、件数が多いと一気に重くなる。スペックだよりのシステムはいずれダメになります。
ということでインデックスを貼ってみるとどうなるか。
インデックススキャン
EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 3;
QUERY PLAN
------------------------------------------------------------------------------
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..10.00 rows=2 width=244)
Index Cond: (unique1 < 3)
「Index Scan」となるとIndexが適用されて抽出ができている状態になっていることがわかります。
今は魔法みたいな感覚でインデックスを張っている
正直、インデックスの仕組みがわかっていないこともあり、どういう組み合わせで作るのがいいのか思考錯誤しているところですが、すごく変わります。
インデックスを貼ると容量を食いますが、CPU使用率は抑えらるし処理速度も早くなります。
インデックスにも種類がありますが、基本はBtreeなのかな。
この当たりもふくめて色々勉強中です。
