あ、追伸です。

CREATE TABLE文の中では
「もともとプライマリーキーだった」serial_codeにUNIQUE制約がありませんでしたが、
> index idxserial_mst_serial_code ( serial_code )

UNIQUE KEYの場合fast index
creationが効かなくなりますので、innodb-sort-buffer-sizeはいじっても効果がないです。


yoku0825,


2015年4月9日 1:13 yoku ts. <yoku0825@xxxxxxxxxx>:
> こんばんは、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

>>

>>

>>

>>