limit 付きで update を行うと何故怒られるか
DESCRIPTION
TRANSCRIPT
厳密に正確な情報じゃないです
ソースまでは追ってません
意図的な単純化もあります
一応 MySQL5 以降が前提
注意
2011年7月2日土曜日
!!!怒られる!!!レプリケーションを行っている状態で
UPDATE 文に
LIMIT 句があり
ユニークな ORDER BY 句が指定されていないMaster/Slave の不整合により
レプリケーションが止まる恐れがある=> ヤバい！！！
2011年7月2日土曜日
Why?2011年7月2日土曜日
順に説明します
レプリケーションとは
インデックス検索は何故速いか
オプティマイザとは
2011年7月2日土曜日
レプリケーションとは1 台の Master から N 台の Slave に同期を取る
バイナリログによる通知を行う
同一の状態で
同一の操作を行えば
同一の結果が得られる
2011年7月2日土曜日
レプリケーションとは1 台の Master から N 台の Slave に同期を取る
バイナリログによる通知を行う
同一の状態で
同一の操作を行えば
同一の結果が得られる
そうじゃないこともある！！ヤバい！！！
2011年7月2日土曜日
バイナリログの設定ステートメントベースSQL 文そのまま
行ベース更新されたデータそのもの
両方を状況に応じて使うこともできる
2011年7月2日土曜日
ステートメントベースだと同じ状態に対して同じ操作をしても結果が不定になりうる
2011年7月2日土曜日
詳しくは@nippondanji さんの
Art of MySQL Replicationを
http://www.slideshare.net/nippondanji/art-of-mysql-replication-4824469
2011年7月2日土曜日
インデックス検索は何故速いか
B-Tree というデータ構造
キーと行への参照的なものから成る
データはソートされている
関係無い行を効率良く捨てる
2011年7月2日土曜日
ID 名前 年齢1 Richard 242 Tom 643 Aaron 234 Tony 125 Ritchie 336 Jimmy 477 Eric 538 James 59 Kirk 8410 Lars 43
2011年7月2日土曜日
ID 名前 年齢3 Aaron 237 Eric 538 James 56 Jimmy 479 Kirk 8410 Lars 431 Richard 245 Ritchie 332 Tom 644 Tony 12
2011年7月2日土曜日
どのインデックスを使うかは
オプティマイザが判断する
2011年7月2日土曜日
オプティマイザとは
検索最適化を担当する
統計情報から一番最適と思われるインデックスを選択
2011年7月2日土曜日
RDBMS 一般におけるオプティマイザ
ルールベースクエリ -> インデックスの選択が静的
コストベースクエリ -> インデックスの選択が動的
MySQL はコストベース
2011年7月2日土曜日
まとめると...
検索時に使用されるインデックスは不定
サーバごとに違う行が UPDATE される可能性
ヤバい!!!
LIMIT には気をつけましょう
2011年7月2日土曜日