MySQL
DB

速度を担保したい時のDBの設計

概要

実装する前の設計の段階で速度を制限してしまう要素を入れると、どんなに頑張ってもそれ以上いけないぜということがあると知ったので、まとめる。

実行速度を担保するために設計で考えておくべきこと

  1. インデックス
  2. 一つのテーブルのカラム数
  3. テーブルのエンティティの関係
  4. NULLが入っているかどうか
  5. スロークエリになりやすいSQLを書かない

大体この辺り。

1. インデックス

これはよく知られている方法。UXを追っていけば、ユーザがどのテーブル、カラムをよく使うのかが大体わかる(サービスの種類によってもそうかも)はずなので、まずは仮定を元に実装しておき、問題が出そうな段階でデータ分析を元に変えるのが良い。ただし、サービスが大きくなりすぎると、インデックスを貼りなおずのも一苦労なので、その辺りはしっかりと見極めが必要。

2. 1つのテーブルのカラム数

これはSELECTで必要な情報を引き出す時にメモリをどれくらい必要とするかということがキモになる。実装の際に、必要なカラムのみをSELECTするなどの対応でどうにでもなる部分もある。しかし、引き出す行数によっては問題になるので、こちらも意識しておく。

3. テーブルのエンティティの関係

サービスによってはJOINしない方が良い(例えば、ソーシャルゲームとかは速さ重視なので)ので、カラム数が多くなるけど、一つのテーブルとするという方法もあるが、基本的にはわかりやすい構成にすることも多い。自分が作るサービスがどんな特性を持つかを考えて構成を選択する。

4. NULLが入っているかどうか

  1. と関連した内容となる。インデックスは基本的にNULL以外のものの検索に関して大いなる力を発揮する。NULLはその対象外となるため、何か意図がない限りはインデックスが聞く状態にするためにNULL許可にしない方が当たり障りがないはず。

5. スロークエリになりやすいSQLを書かない

この辺りを見てもらいつつ。実行計画でALLが出ないように気をつけていれば、最初のうちは大丈夫。また、fetchAllを使用する箇所には特に注意が必要。fetchする箇所がデータ量が多くなりやすいようであれば、そこは最悪LIMITで制限するなどの対策をしても良いかもしれない。

MySQL スロークエリ改善 初心者向け