普通に使える。 単純に二つのテーブルをくっつけて一つのテーブルにしたと思えばよし。

みたいなクエリを実行すると、 mosaが0のレコードはHITしない。 なぜ・・・？ ※調査結果 答えは簡単。 上の式をわかりやすく解釈すると ってことで、WHEREを解釈した時点でレコードがあればORDER BYするって…

主キーはテーブルにひとつだけ設定できるってことらしいが、 みたいな構文が通るのは何故？ ２つのフィールドで一つのプライマリキーとして扱うのかな。 確かそんなのがあったようななかったような。 ※調査結果 複合キーってことだ…

答えは兼ねない。 が、auto_incrementを設定するには主キーかインデックスを設定する必要があるので、 auto_incrementが設定されたフィールドは主キーも設定されている割合が高い。

JOINは遅い。 のでできれば使わない方がいい。 いや、テーブルの設計上は楽になるんですけどね。

ORも遅いので、できるだけ使わない方が良い。

まぁ、常識っすね。 絞込みをしっかりしろということ。

これの違いってなんだ？ 対象であるmosaフィールドがユニークかどうかってこと？ ユニークインデックスと、通常のインデックスを二重で定義するのってアリ？ その場合のメリットは？ ※調査結果 まだよくわからんが、実践ハイパ…

実践ハイパフォーマンスMySQLの66pより引用すると 「MySQLでは、１つのクエリを実行するとき、１つのテーブルにつき１つのインデックスしか使用できない」 ということらしい。 だから、複数のシングルカラムインデックス…

みたいな感じ。 クエリ実行→結果セット取得→レコード取得→フィールド参照→結果セット解放 って暗記しとけ。 あと、結果セットを解放しても、rowが解放されるかどうかは、MySQLクライアントライブラリが状況に応じて判断す…