基本に戻ってInnoDBの話をします
Upcoming SlideShare
Loading in...5
×
 

基本に戻ってInnoDBの話をします

on

  • 5,550 views

2013/11/30 Chiba.pm #4

2013/11/30 Chiba.pm #4

Statistics

Views

Total Views
5,550
Views on SlideShare
5,533
Embed Views
17

Actions

Likes
22
Downloads
30
Comments
0

2 Embeds 17

https://twitter.com 16
https://www.chatwork.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    基本に戻ってInnoDBの話をします 基本に戻ってInnoDBの話をします Presentation Transcript

    • そろそろ基本に立ち戻って InnoDB の話をします か? 2013/11/30 yoku0825 Chiba.pm #4.1
    • Hi, All! I'm very sorry. Today, I don't talk about Percona たいへんもうしわけありませんが、 きょうは Per
    • Hi, All! I'm very sorry. Today, I don't talk about Percona たいへんもうしわけありませんが、 きょうは Percona のはなしを
    • Hi, All! I'm very sorry. Today, I don't talk about Percona たいへんもうしわけありませんが、 きょうは Percona のはなしをしません
    • Σ (゚ д ゚ lll ) えっ
    • 今日は MySQL の話をします \安定の Chiba.db /
    • みなさん、 InnoDB 使ってますか?
    • What is most important parameter for InnoDB?
    • innodb_buffer_pool_size
    • Why?
    • What's InnoDB Buffer Pool?
    • InnoDB テーブルの データとインデックスの キャッシュ領域?
    • 間違いじゃないけど、 それだけだとこれの説明がつかなくなる
    • mysql> SHOW CREATE TABLE t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `num` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `val` varchar(32) DEFAULT NULL, UNIQUE KEY `num` (`num`), KEY `val` (`val`) ) ENGINE=InnoDB AUTO_INCREMENT=100000001 DEFAULT CHARSET=utf8mb4 1 row in set (0.03 sec) 【 innodb_buffer_pool_size= 4G 】 $ time bin/mysql -uroot d1 < ~/dump.sql real user sys 344m4.664s 1m32.631s 0m5.872s 【 innodb_buffer_pool_size= 32M 】 $ time bin/mysql -uroot d1 < ~/dump.sql real user sys 1222m16.982s 1m47.038s 0m6.243s
    • 更新も速くなる ということは、ライトキャッシュも兼ねてる?
    • 今度はこれの説明がつかない
    • 【 innodb_buffer_pool_size= 4G 】 mysql> DROP TABLE t1; Query OK, 0 rows affected (2.20 sec) 【 innodb_buffer_pool_size= 32M 】 mysql> DROP TABLE t1; Query OK, 0 rows affected (1.86 sec)
    • うわテストケース微妙すぎた。。 トラフィックがあってバッファプールが数十 GB になると バージョンにもよるけど目に見えて違います ( 最近のはだいぶマシ )
    • なんで?
    • 俺は ` バッファプールこそが データ原本だから ' と説明することにしてる
    • SELECT のとき ● ● ● バッファプール見る あればそれを使う なければテーブルスペースファイルを読んで バッファプールに載せる
    • INSERT, UPDATE, DELETE のとき ● バッファプールに書く ● ● ● バッファプールに空きがなければ、古いページを押 し出してから書く DELETE でさえも、書く その後、ログファイルに書く ● ● ● 非同期でログファイルを読んでテーブルスペース ファイルに書く テーブルスペースファイル + ログファイルで初め て完全なデータ バッファプール上にあってテーブルスペースファイ ルにないデータ ( ダーティページ ) が一定割合を超 えると強制チェックポイント
    • DROP のとき ● ● そのテーブルの全てのページをバッファプール から追い出す その後、ログファイルに書いたりテーブルス ペースファイルが削除される
    • 常に最新の情報はバッファプールと ログファイルに書き込まれる
    • バッファプールが足りないと しょっちゅうストレージアクセス
    • まずは、これを足りさせること RDS とかで Memory か IOPS かって思ったら まずは Memory に突っ込んだ方が良い
    • 次にログファイル
    • innodb_log_file_size × innodb_log_files_in_group
    • 基本的にログファイルの性能はこの値に依存する 64M* 3 と 96M* 2 はほぼいっしょ
    • 5.6 未満だと、ログファイルサイズを変える , ログファイルの数を減らすのにちょっと手間 ファイルを増やすのは再起動だけで OK
    • 1 つでも壊れたらアウトなので、 個人的には 2 つを推奨
    • ログファイルが詰まると 全ての COMMIMT が詰まる
    • innodb_flush_log_at_trx
    • 毎回は fsync せず write だけで終わらせるので ログファイルの詰まりが減る
    • ただし fsync していないので Durability を犠牲にしているのを忘れずに
    • innodb_file_format
    • * 個別テーブルスペースファイルの * ファイルフォーマット 共有テーブルスペースは関係ない
    • Barracuda 一択で良いが、 それだけで性能は変わらない
    • innodb_io_capacity innodb_*_io_threads
    • SSD とか RAID とか、 IOPS が高いなら上げる HDD 1 玉なら触らない方が無難
    • 他にも色々
    • 真面目に調べ始めると奥が深くて楽しい
    • Chiba.pm の m は MySQL の m
    • 楽しみましょう :)
    • ご清聴ありがとうございました