お仕事で作ったテーブル、SQL文のチェックに使いたいのでまとめます。
##テーブル定義
###インデックスを作る列
（B-treeインデックスのこと。ほかって何？？➡ビットマップ、ハッシュ）
| ☑️ | 方針 | 注意すること |
|---|---|---|
| カーディナリティの高い列であること。 | （種類がいっぱいあって、データが偏っていないと良く効く） | |
| 検索条件に利用する列であること。 | （インデックスも容量を食ったり、更新性能に影響するから使うとこだけ指定する） | |
| テーブルの結合に利用する列であること。 | （どんな条件で検索されるか検討する） | |
| 主キー、一意制約の列にインデックスを作らないこと。 | （そもそも作ってくれている） |
##SQL
###インデックスの列を利用するとき
| ☑️ | 方針 | 注意すること |
|---|---|---|
| 「<>、!=」で検索をしないこと。 | （インデックスが効かないから） | |
| 計算や関数の適用をしないこと。 | （比較する値の方で、例えば1/10➡*0.1など工夫する） | |
| IS NULLをなるべく使わないこと。 | （DBよっては問題ない場合もあるらしい） | |
| ORを使わないこと。 | （INで書き換えるなどする。NOT INはインデックスがたぶん効かないのかな？まあ、ORにはいい思い出が無い・・・） | |
| LIKEは前方一致で検討すること。 | （私はあまりLIKE使ってない） | |
| 数字の列を文字で検索したりしないこと。 | （型の変換がされてしまう） | |
| 時々はインデックスを再構築しておくこと。 | （大量のデータを入れた後とかでいいかも） |
###パーティションの方針
| ☑️ | 方針 | 注意すること |
|---|---|---|
| データ量が多くなったら検討すること。 | （データ量が大きくなってテーブルを水平分割するとかの前に検討する） | |
| インデックスよりも種類の少ない（十から数十程度）データ量を持つ列を指定すること。 | （ざっくり絞り込んでからインデックスで特定するという使い方） | |
| 値が変化しにくい列を指定すること。 | （年度とか都道府県とか。値が変更になるとパーティションをまたいで性能低下の原因になるらしい） | |
| 各パーティションに格納されるレコードが均一に近づくようにすること。 | （どこか偏ってしまうと効果が下がるので） | |
| 選択条件、結合条件に利用する列を指定すること。 | （使う列を指定しないと意味が無い。インデックスを貼るには種類が少ないかもっていう時に検討したい） | |
| 一意にレコードを特定する目的のテーブルならハッシュパーティションも検討すること。 | （ハッシュ関数を使って均一に振り分けてくれることを期待する） |
気がついた事はどんどん追記していくようにしたい。
##From
達人に学ぶDB設計徹底指南書 by ミック様
良書です。エンジニア２年生くらいのときに読みたかった・・・。