dumpした大容量sqlファイルでDBを構築－IT版本当にあった怖い話（レベル8）

途中までは、よくある話。

「dumpしたsqlファイル送るからそっちのローカルに構築してー。」
「らじゃー」

dump.sqlをデスクトップのworkという名前のフォルダに放り込んだよ。

mysql -uroot
source ~/Desktop/work/dump.sql;

結果、SQLエラー。

「あれー？このsqlファイルってどうやってdumpしたの？DB作るところから書かれてる？テーブルは無条件にcreate？」
「んーとねー、phpMyAdminで適当にエクスポートしたからわかんなーい」
「がっでむ」

適当なサイズのsqlファイルならエディタで開いて中身確認してよきように書き換えて実行すればいい。

でも超巨大なsqlファイルだったら？

普通のエディタでは開きません。

いろいろ試した結果、Macで大容量ファイルを開くにはGrep が良いという結論に。
（もっと良いのあったら教えてください）

Grepでdump.sqlを開く。
要は最初の方の処理だけ見られれば良いのです。
全部開く必要はありません。

覗いてみた結果、CREATE DATABASEが書かれてないことがわかりました。
書かれていないなら書けばいい？
そう、普通のサイズならね。
超巨大sqlファイルなので、何か（CREATE DATABASE）を書いて保存する行為は怖いから避けることにする。

ということは、受けて側のDBの中身を空にする必要がある。
けどMySQLには「DBを空にする」というコマンドはありません。
（「テーブルを空にする」ならあります。）
なので一旦DBを削除して、それから同名の空っぽのDBを作ります。
これで「DBを空にする」ことができます。

しかし怖いですねー。
DROP DATABASEなんてあまり実行したくありません。
今回のケースはローカルにテスト環境を作るから、まあいいです。
本番環境では超注意。
っていうかDROPが良いか悪いかではなく、作業計画をきちんとたてましょう。

そういえば昔昔の大昔、こんな会話を聞いたことがあります。
（私の周囲での話ではないよ）

「ぼくねー昔ねー本番環境で顧客10万人分のDBを間違ってDROPしちゃったんだよねー」
「こわいですねー（そーゆーのクチに出さないでよー）」

IT版本当にあった怖い話。（レベル8）

そんなことを思い出していたら空のDBができたので、dump.sqlをコマンドで流しこめます。

MySQLにログインして
mysql -uroot

レッツ実行。
mysql> DROP DATABASE test;
mysql> CREATE DATABASE /*!32312 IF NOT EXISTS*/ test /*!40100 DEFAULT CHARACTER SET utf8 */;
mysql> USE test;
mysql> source ~/Desktop/work/dump.sql;

こうしてDBができました。