Keyのないカラムを使ってUPDATE,DELETEすると、
当然フルスキャンが発生するので処理にかかる時間は当然延びる。
UPDATE,DELETEの処理が長引くってことは、ロックがかかりっぱなしになる時間が延びる。
さてところで、MyISAMはテーブルロック、InnoDBは行ロックってことになっているので、
`InnoDBならちょっとくらいUPDATEでロックかかってても他のレコードは読み書きできるじゃん'と思うがさにあらず。
全行いっぺんにロックするよ!
更新系DML、全部待たされるよ!
`='演算子でもダメだよ!
技術的な話は公式にお任せとして、`月に1度しかないバッチだから遅くても良いや'くらいのつもりでいると
オンライン系の処理が全滅するのでとても注意。
http://dev.mysql.com/doc/refman/5.5/en/innodb-record-level-locks.html
あ、あとこの現象、`全ての行をロック'なのであって`テーブルロック'ではないです。
一緒といえば一緒なんだけど、InnoDBはロックエスカレーションしませんので(←ここ試験で間違えた)
かといってINDEXをべたべた作ってもなぁ、というのも体感してみた。
⇒INDEX作ると更新がどれくらい遅くなるのかという。
結構重くなるのね。
当然フルスキャンが発生するので処理にかかる時間は当然延びる。
UPDATE,DELETEの処理が長引くってことは、ロックがかかりっぱなしになる時間が延びる。
さてところで、MyISAMはテーブルロック、InnoDBは行ロックってことになっているので、
`InnoDBならちょっとくらいUPDATEでロックかかってても他のレコードは読み書きできるじゃん'と思うがさにあらず。
全行いっぺんにロックするよ!
更新系DML、全部待たされるよ!
`='演算子でもダメだよ!
技術的な話は公式にお任せとして、`月に1度しかないバッチだから遅くても良いや'くらいのつもりでいると
オンライン系の処理が全滅するのでとても注意。
http://dev.mysql.com/doc/refman/5.5/en/innodb-record-level-locks.html
あ、あとこの現象、`全ての行をロック'なのであって`テーブルロック'ではないです。
一緒といえば一緒なんだけど、InnoDBはロックエスカレーションしませんので(←ここ試験で間違えた)
かといってINDEXをべたべた作ってもなぁ、というのも体感してみた。
⇒INDEX作ると更新がどれくらい遅くなるのかという。
結構重くなるのね。
0 件のコメント :
コメントを投稿