そろそろ基本に立ち戻って
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
楽しみましょう :)
ご清聴ありがとうございました

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