mysqldumpによって作成された膨大な行長に対処する方法
私はmysqldumpをcronジョブで使用して、200万行を超えるデータベースをバックアップしています。
コマンドラインからデータログを復元するために使用できるテキストファイルを作成します。
値とテーブルまたは列の名前を変更するquick方法として、復元の前にダンプを編集することは有用だと思いました-少なくとも詳細を学ぶまでそして、ALTERとUPDATEでそれを行うことに自信を持ちます。
大きなテキストファイルを編集しても問題はありませんが、データベースの250メガバイトダンプに約300行しかなかったであることに気づいて驚いた。各行は800k文字のようなものでした。
行の長さをより細かく制御してダンプを生成する別の方法はありますか？
または、sedやPerlなどのツールでダンプを後処理する必要がありますか？
デフォルトでは、mysqldumpはINSERTコマンドを1つだけ生成しますテーブルごと。その結果、ダンプされたテーブルごとに1行（非常に長い）の挿入データ行が挿入されます。これは基本的に、「バッチ」挿入が、すべてのテーブルのすべてのレコードに対して個別のINSERTクエリを生成する場合よりもはるかに高速であるためです。
したがって、mysqldumpが任意の長い行を作成したわけではなく、他のカットオフ長を課すことができます。行は理由のために長いです。
INSERTsを複数行に分割することが本当に重要な場合は、次のように指定できます。
mysqldump --extended-insert=FALSE --complete-insert=TRUE ...
ただし、この形式ではテーブルの復元に時間がかかることに注意してください。
今日、この問題の解決策を探すためにMySQLソースコードを閲覧していました。行の最大長は、MySQLサーバーのバッファーサイズと一致するはずの変数opt_net_buffer_lengthによって強制されます。コミカルに大きいです。
とにかく、それはオプションなので、これを実行してください：
mysqldump --net_buffer_length=5000 ...
最小値は4096です。
MySQLフォーラムで回答を見つけました。ソースを変更せずにmysqldumpだけを使用して各INSERTグループを追加できない場合は、最終的に「\ n」を追加することを示しています。
拡張形式は、カンマまたは括弧に基づいて100％正しく解析できません。フィールドをカウントします。最善の解決策は、mysqldumpを出力の改行に修正することです。
非常に小さな変更：3506行目で、行の終わりのコンマが出力される場所を確認できます。
fputc(',',md_result_file); /* Always row break */この行を3506行の直後に挿入するだけです。
fputc('\n',md_result_file); /* Lon Binder says wrap that line! */再コンパイルして行います。
@see http://forums.mysql.com/read.php?28,420002,426110#msg-42611
ロンB、ありがとう！
（フォーラムが消えた場合に備えて、MySQLフォーラムのコンテンツを含めました。）
このフラグも機能します：
mysqldump --skip-extended-insert
--extended-insert=FALSEと同じです。
正規表現を使用して行を分割するだけでは不十分です。引用符とエスケープ文字を正しく理解するパーサーが必要です。
パーサーを見つけられなかったので、作成しました： http://blog.lavoie.sl/2014/06/split-mysqldump-extended-inserts.html