そろそろ基本に立ち戻ってInnoDBの話をします

か？

2013/11/30yoku0825

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 parameterfor InnoDB?

innodb_buffer_pool_size

Why?

What's InnoDB Buffer Pool?

InnoDBテーブルのデータとインデックスの

キャッシュ領域？

間違いじゃないけど、それだけだとこれの説明がつかなくなる

mysql> SHOW CREATE TABLE t1\G*************************** 1. row *************************** Table: t1Create 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=utf8mb41 row in set (0.03 sec)

【 innodb_buffer_pool_size= 4G】$ time bin/mysql -uroot d1 < ~/dump.sql

real 344m4.664suser 1m32.631ssys 0m5.872s

【 innodb_buffer_pool_size= 32M】$ time bin/mysql -uroot d1 < ~/dump.sql

real 1222m16.982suser 1m47.038ssys 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_capacityinnodb_*_io_threads

SSDとかRAIDとか、IOPSが高いなら上げる

HDD 1玉なら触らない方が無難

他にも色々

真面目に調べ始めると奥が深くて楽しい

Chiba.pmの mは MySQLの m

楽しみましょう :)

ご清聴ありがとうございました