yoku ts.様
二見です、お世話になっております

下記の件

ご教授ありがとうございます
参考にさせて頂き、色々試してみます！

以上、よろしくお願いいたします

On Thu, 9 Apr 2015 01:49:33 +0900
"yoku ts." <yoku0825@xxxxxxxxxx> wrote:

> あ、追伸です。
> 
> 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
> >>
> >>
> >>
> >>

※部署名が変わりました
-------------------------------------------------------
  DNP DIGITALCOM
　システムソリューション本部
  第１システム開発室　第２グループ
　　　二見　修康

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

    TEL 03-6431-6324 内線 6324
    FAX 03-6431-6193
　  Mail: Futami-N2@xxxxxxxxxx