前回のBaserCMS勉強会で @itm_kiyo さんがLTで話してましたPostgresのチューニング。BaserCSMでPostgresを使った場合、INDEXがあまり貼られていないので貼ったほうがいいというお話。 時間がなくてサラっと流されたんですが、いいお話だったのでもうちょっと詳しくDBを見ながらやってみました。※スロークエリの分析は重要です。一応ちゃんとスロークエリの分析を参考に統計取ってます。ただその説明はめんどくさいので省きます。今回は統計＋感どころのチューニングです。ちゃんとやる場合は統計とってやってくださいね☆DBを覗くといろいろなテーブルが出てきますが、今回はブログに注目。一番更新しますからね。BaserCMS 1.6.14で使われているブログ関係はこれぐらいの様子。public | bc_pg_blog_categories | table | postgrespublic | bc_pg_blog_comments | table | postgrespublic | bc_pg_blog_configs | table | postgrespublic | bc_pg_blog_contents | table | postgrespublic | bc_pg_blog_posts | table | postgrespublic | bc_pg_blog_posts_blog_tags | table | postgrespublic | bc_pg_blog_tags | table | postgres インデックスは直訳すると「索引」と言われていますが、個人的には「潤滑油」ぐらいのイメージのほうがしっくりきます。テーブルとテーブルの繋ぎこみ（JOIN）している部分や、検索（Where）に使われているところに チュッ と差し込んでやると駆動が良くなります（笑）ただしどこでもかしこも油差し過ぎると、逆に良くないですよ。と。 で、ブログの記事を記録しているのはbc_pg_blog_postsのテーブルのようです。ここにタグやらコメントやらが紐つくので重くなっている様子。 IDの部分は大体JOINに使われているし、状況によって増えそうなテーブルが多いのでここには全部INDEX貼っちゃいましょう。おそらくnoあたりもsortに使ってそうなので貼っときます。CREATE INDEX blog_category_id_idx ON bc_pg_blog_posts(blog_category_id) ;CREATE INDEX blog_content_id_idx ON bc_pg_blog_posts(blog_content_id) ;CREATE INDEX user_id_idx ON bc_pg_blog_posts(user_id) ;CREATE INDEX bc_pg_blog_posts_no_idx ON bc_pg_blog_posts(no) ; それからブログとタグをひもづけてるbc_pg_blog_posts_blog_tags 。タグを使う場合こいつは臭い。この辺、INDEX貼ればかなり変わりそう。 CREATE INDEX blog_post_id_idx ON bc_pg_blog_posts_blog_tags(blog_post_id) ;CREATE INDEX blog_tag_id ON bc_pg_blog_posts_blog_tags(blog_tag_id) ; あとはコメントのテーブル。bc_pg_blog_comments もしサイトが炎上してコメント１０００も２０００も行った場合はここも負荷になるのでINDEX貼っときましょう。 CREATE INDEX blog_comments_content_id_idx ON bc_pg_blog_comments(blog_content_id) ;CREATE INDEX blog_comments_post_id_idx ON bc_pg_blog_comments(blog_post_id) ;CREATE INDEX blog_comments_no_idx ON bc_pg_blog_comments(no) ; できました。 これでブログ関係はOKです。詳しくデータは取ってませんが（INDEX後のコストデータは）だいぶ早くなった気がする。 次は一般のページ関係に関わるチューニングをやりたいと思います。ページチューニング編