SQLアンチパターン本購入。

SQLアンチパターン

ID リクワイアド(とりあえずID)
⇒他のテーブルで共通名でいいから分かりやすい名前を
ジェイウォーク
⇒交差テーブル
キーレスエントリ(外部キー嫌い　※アプリ内で整合性を取ろうとする、アプリ以外からゴミデータが入る場合がある)
⇒外部キー制約を宣言する
とりあえず削除フラグ
⇒状態を持たせる
NEWや、有効、中止、キャンセル、廃止予定など
⇒全てのテーブルに削除フラグはおかしい。
⇒削除は設計不足を示す
お客様は本当に削除と言っているのか。
⇒フラグ以外もある。
更新、削除をしない世界もある
⇒よく考えた上での削除フラグならOK
ポリモーフィック関連
⇒交差テーブル
マルチカラムアトリビュート
⇒複数の列ではなく、複数の行に。従属テーブルを作る。
メタデータトリブル　※年が変わる度にテーブルや列を追加している。
⇒パーティションニングと正規化で対応
シュードキー・ニートフリーク (擬似キー潔癖症。欠番を埋めてしまう）
⇒欠番は埋めない。

時代はBIGINT
http://hamamuratakuo.blog61.fc2.com/blog-entry-648.html

設計時にintとbigintで悩むよね
http://snowland.net/nucleus/item/3014

MENTORの原則

Measure(測定)
EXPLAIN（解析）
Nominate(指名)
Test(テスト)
Optimize(最適化)
Rebuild(再構築)

クエリ

スパゲッティクエリ・・・１ステップで解決しようとする。
⇒UNION等を使い、分割してワンステップずつ解く。
インプリシットカラム(暗黙の列)　※*で不必要な列まで取得する。定義変更によりバグの元になる。
⇒SELECTはきちんと列を明示的に指定する。

MySQLテーブル設計入門

MySQLテーブル設計入門 from yoku0825

考え方の順番

最初に全部入りで考えてみる P22
正規化とか考えずに必要なものを全部テーブルに詰め込んで見る
正規化手順に沿って５NFまで持っていく
もちろん慣れていれば３NFくらいからいきなり書き始められる。

NULLでないこと。P48
原則的にNOT NULL制約をつける

　・テストケースが膨大に増える。
・演算になれていないと分析に時間がかかる。
TRUE and NULL => NULL
FALSE and NULL => FALSE
TRUE or NULL => TRUE
FALSE or NULL => NULL

都市伝説 P89

MySQLを使うなら遅くなるから正規化してはいけない？なぜRDBMSを扱う上で正しい正規化でレスポンスが悪くなるの？

確かにMySQL5.5以前は遅くなるケースもある
プライマリーキーを使った結合なら大概ちゃんとした速度で動く。NLJなので数百万件に達すると遅くなる。
JOINすると遅くなるのは多くの場合ソート、綺麗にインデックスを使いきれていないケース

複合インデックスが思った通りに使えないパターン P117

OR演算子
IN演算子
不等号演算子
ASC, DESCの混在
JOINの結合順序

Using Filesort ※クイックソート sort_buffer_size
http://nippondanji.blogspot.jp/2009/03/using-filesort.html

Filesortとはクイックソートのことである。

JOINにおいてORDER BYが指定されているとき、ソートが行われるタイミングは3種類ある。

Using filesortがEXPLAINに出ていないときはインデックスを用いてソートが行われている。（最も高速。）

Using filesortだけがEXPLAINの最初の行に出ている時は、先にソートしてからJOINが実行されている。

Using temporary; Using filesortがEXPLAINの最初の行に出ている時は、先にJOINしてからソートされている。（最も遅い。）

WHERE句による検索条件とORDER BYにおけるソート条件は、一つのテーブルに集中させる。

JOINにおいてソート処理する場合には、LIMIT句が適用されるのはJOINとソートが完了した後である。

LEFT/RIGHT JOINの場合には、LIMIT句の問題はサブクエリである程度対策が可能である。@see http://nippondanji.blogspot.jp/2009/03/using-filesort.html

⇒インデックスが使われるようにチューニングする。

すぐに絶対に読み切らならなければいけない本が６冊溜まってしまっている。消化します。