- Published on
MySQLとお友達になりたい
- Authors
- Name
- Riki "Remicck" Kawai
- @Ricckn
昔はPostgreSQLとかSQL Serverとかも使ったことがあるけど、WordPressから始まって今のCRMも含めてかなりの期間をMySQLを使ったシステムと共にある。
長い時間やっているとは言え、すっごい深いところばかりを扱うわけでもなく、ゆるーくMySQLについて学んでいるような感じで思い返せばそろそろ10年とかになることがわかってびっくりした。
さて、DBというと設計自体が死ぬほど大事なんだけど、関連して直結してくるのが速度低下(スロークエリ)だと思う。
これは日々日々起きる可能性があって、なんだかんだ頻繁に対応することがある。
うちが扱ってるシステムはもともと別のOSS CRMをベースに、ローカライズやその他カスタマイズを入れて出しているものだから、それなりに年季が入ったものだ。
年季が入っているからというわけでもないけど、その割にはしっかりとしたフレームワークがあって、「絶対Java屋が作っただろこれ」って感じの設計になっている。悪い意味ではなく。
同時に、「あー・・・?」なDB設計みたいなものがあって、ちょいちょい苦しめられることになる。
苦しみ
たとえばLaravelとかRailsとかで設計を行うと、自然にModelごとに個別のIDを振っていくよな設計になると思う。
しかしうちのシステム、共通のID基盤用テーブル(ここではtable_aとする)があって、それぞれのModelは歯抜けでIDを持っている(table_b)ような感じの設計になっている。
良い面も悪い面もあるけど、table_a
側にmodifiedtime
とかを持っていることで、更新順で降順にするケースのとき(うちはデフォルトがほとんどこれ)検索条件はtable_b
側にあって、order by
はtable_a
側のtable_a.modifiedtime
になるのでindexがいいカンジに効かなくてフルスキャンが走ることになる。