MySQLでMyISAMからInnoDBに乗り換える際に知らないとハマる、怖い話 - Y-Ken Studio
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
MySQLのテーブルを好きな形式（XML/HTML/SQL）で取り出したり、データをちょっと取り出して実験したいときのテクニック - それマグで！
データをちょっと取り出して実験したいときに、mysqldumpのSQLを編集するのが面倒だし、DELETEを書くのが面倒だった。 MySQLのテーブルの指定行を様々な形式で取り出したい。コマンドのみでMySQLのテーブルを取り出せる形式をまとめてみた コマンドで取り出せる形式は次の通り。 SQL HTMLテーブル XML テーブルの部分コピー これらであれば、簡単にテーブルをSQLとして取り出すことが出来る。 １：テーブルをHTMLのテーブルで取り出す。 mysqlコマンドで結果をHTMLに出力する。 よく見かける例なので有名かも。最近のSQLサーバーなら一般的にサポートされている。 形式 echo "ここがSQL" | mysql -p -u ユーザー名 DB名 -H -H --html 出力をHTMLテーブルにする。 実例 echo 'set names utf8;select * f
長年の議論に終止符 -- MySQL/MariaDBのバックアップとロックの関係＋クラッシュセーフについて - interdb’s diary
よい機会なのでまとめておく。対象はMySQL5.6以下とMariaDB10.0以下。 (2014.12.3追記：以下の書籍にも記述した。) 要旨 MySQL/MariaDBのバックアップについて、相変わらず「InnoDBさえ使っていれば、FLUSH TABLES WITH READ LOCKは不要。よってバックアップ中に更新不可になることはない！」との主張が繰り返されているが、少なくとも5.6/10.0まではそんなことはない。 オンラインバックアップに関するロックの正確な記述 より正確に言えば「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLバックアップの基本
