こんばんは、yoku0825といいます。

ぱっと思いつくところをつらつらと。。

MySQLは好きに再起動できる、データロードは初期データのロードだけで、その後はバルクロードされることはない、と仮定しての話です。


## あとでもとに戻すもの
* skip-innodb-doublewrite # ロード中にクラッシュしたらやり直す
* innodb-flush-log-trx-commit= 0 # 同上
* innodb-log-buffer-size= 256M # もうちょっと大きくてもいいかも
* innodb-log-file-size= 2G, innodb-log-files-in-group= 4 くらい #ログファイル大きめ
* innodb-sort-buffer-size= 64M # ALTER TABLE用
* innodb-adaptive-hash-index= 0 # I/Oバウンドならこれで良いかと

## 様子を見ながら
* innodb-io-capacity= innodb-io-capacity-max #
I/Oが遊んでいるようであれば増やす(HDD1玉ならデフォルトのままでもいいかと)

## 効果があるかはわからないですが
* innodb-autoextend-increment= 256M # .ibdファイルの拡張単位,
innodb-file-per-table= 0の時にibdata1を大きめに初期化するのと同じ考え

でMySQLを起動して、
* セカンダリーキーはつけないでCREATE TABLE
* LOAD DATA INFILE (handlersocketとか使ってみるのもよさそうな予感がします)
* ALTER TABLE serial_mst ADD KEY .. (serial_code);
ここでパラメーターを戻して再起動、とわたしならこうやります。

前にやった時の記事が出てきました（もともとの目的は違いましたがバルクロードの速度比較みたいになってる）

日々の覚書: MySQLインスタンス間でテーブルを移行する投げ遣りベンチマーク
http://yoku0825.blogspot.jp/2013/11/mysql.html



その他、手前味噌なものも含めてご参考までに。。

漢(オトコ)のコンピュータ道: たった3秒でInnoDBのデータローディングが快適になるライフハック
http://nippondanji.blogspot.jp/2010/03/innodb.html

MySQL 5.6における大量データロード時の考慮点 - SH2の日記
http://d.hatena.ne.jp/sh2/20131007

忙しい人のための MySQL 5.7.6 DMR における InnoDB Flushing の変更点について | GREE Engineers' Blog
http://labs.gree.jp/blog/2015/03/13735/

日々の覚書: MySQL 5.6.4で実装されたinnodb-sort-buffer-sizeの値
http://yoku0825.blogspot.jp/2014/05/mysql-564innodb-sort-buffer-size.html



yoku0825,

2015年4月8日 21:39 二見　修康[ＤＮＰデジタルコム] <futami-n2@xxxxxxxxxx>:
> 二見と申します、お世話になっております

>

> 久しぶりの投稿となります（2009年以来？）

> ちょっと皆様のご意見を伺いたいのですが・・・

>

> 下記の様な環境にて

>

>>Red Hat Enterprise 5.6

>>MySQL 5.6

>>

>>

>>create table serial_mst (

>> serial_code     varchar(16) not null,

>> serial_seq       bigint(16) unsigned zerofill auto_increment not null,

>> update_date  timestamp,

>>

>> primary key ( serial_seq ),

>> index idxserial_mst_serial_code ( serial_code )

>>) TYPE = InnoDB;

>

> シリアルコードを500万件毎にLOAD DATAしております

>

> メモリは8GありMySQLで5G使用しているとの事です

> 　＃サーバ設定のチームに聞いた情報です、曖昧ですみません

>

> 3億とか4億コードくらい入れるつもりなのですが

> 件数が増えるごとに登録が徐々に遅くなり

> １億3000万件越えた辺りから極端に遅くなってきます

>       0　⇒  500万　1分13秒

> 3000万⇒3500万　2分57秒

> 9000万⇒9500万　4分48秒

>

> 11500万⇒12000万　10分11秒

> 12500万⇒13000万　37分18秒

> 13500万⇒14000万　73分

> 14500万⇒15000万　96分

> 15500万⇒16000万　112分

>

> 19500万⇒20000万　157分

>

> プライマリキーをserial_code⇒serial_seqに変更した事で

> トータルの登録時間が

> 2億件で75時間⇒30時間に多少早くなりました

>

> メモリを増やす事で

> １億3000万件の遅延ポイントを遅らせる事は出来そうですが

> （例えばメモリを倍に増やしてMySQLを10Gにすれば2億6000万近くになると思わ

> れる）

> 何か他に良い方法は無いでしょうか？

>

> まだ試して無いですが、

> Indexを無効にして３～４億データを作成後Indexを貼るとか

> （その場合Indexの生成にもの凄く時間が掛かるとかはちょっと怖いのですが）

>

> 何か良い方法をご存知でしたらお教え頂けると有り難いです

>

> 宜しくお願い致します

>

> ※部署名が変わりました

> -------------------------------------------------------

>   DNP DIGITALCOM

> 　システムソリューション本部

>   第１システム開発室　第２グループ

> 　　　二見　修康

>

>   〒141-8001

>     品川区西五反田3-5-20 ＤＮＰ五反田ビル5Ｆ

>

>     TEL 03-6431-6324 内線 6324

>     FAX 03-6431-6193

> 　  Mail: Futami-N2@xxxxxxxxxx

>

>

>

>