photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった！さあランチタイムだ！ ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO
MySQL5.5からトランザクション処理ができるInnoDBがデフォルトストレージとなりましたし、とりあえずInnoDBにしとこうという風潮から、ストレージがInnoDBであることも多いのですが、実は蓋を開けて見るとまだまだMyISAMで動いているサービスがたくさんあります。今回は運用面から見た両者の違いをみてみたいと思います。 同じMySQLですが、InnoDBの運用とMyISAMの運用は注意するポイントが違います。 ロック方式 一番大きい違いはロック方式の違いでしょうか。InnoDBは行ロック方式(*1)、MyISAMはテーブルロック方式です。データをINSERTやUPDATEする時はセマフォ制御のためロックされますが、その時の挙動が違います。 たとえばUPDATEのクエリを投げると、MyISAMの場合は対象テーブル全体がロックされ、その後のクエリが”詰まり”ます。なので重いクエリを発
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
