MySQL 5.7のinnodb_default_row_format 影響範囲まとめ

日々の覚書: MySQL 5.7.9のinnodb_default_row_formatがまた何か企んでいるようです ではまだ5.7.9が手元になかったので推測でしたが、公開されたので試してみたまとめ。

|PRIMARY KEY|ALTER            |変換|メモ                                          |
|-----------|-----------------|----|----------------------------------------------|
|あり,なし  |ADD COLUMN       |Yes |                                              |
|あり,なし  |DROP COLUMN      |Yes |                                              |
|あり,なし  |ADD FOREIGN KEY  |Yes |                                              |
|あり,なし  |ADD KEY          |No  |ALGORITHM= INPLACE                            |
|あり,なし  |ADD KEY          |Yes |ALGORITHM= COPY                               |
|なし       |ADD PRIMARY KEY  |Yes |                                              |
|あり       |DROP PRIMARY KEY |Yes |                                              |
|あり,なし  |ADD UNIQUE KEY   |No  |                                              |
|あり,なし  |MODIFY, CHANGE   |No  |int => int(カラムリネームのみ)                |
|あり,なし  |MODIFY, CHANGE   |No  |varchar(32) => varchar(32)(カラムリネームのみ)|
|あり,なし  |MODIFY, CHANGE   |No  |varchar(32) => varchar(64)(latin1)            |
|あり,なし  |MODIFY, CHANGE   |Yes |varchar(32) => varchar(256)(latin1)           |
|あり,なし  |MODIFY, CHANGE   |Yes |int => bigint                                 |
|あり,なし  |MODIFY, CHANGE   |Yes |int => int unsigned                           |
|あり,なし  |MODIFY, CHANGE   |Yes |int => varchar(32)                            |
|あり,なし  |Engine= InnoDB   |Yes |OPTIMIZE TABLE                                |
|あり,なし  |ALTER SET DEFAULT|No  |                                              |
|あり,なし  |RENAME           |No  |テーブル名のリネーム                          |

メタデータだけをゴニョる場合（テーブルリネーム、カラムリネーム、デフォルト値の変更）と、ADD KEY(FOREIGN KEY, FULLTEXT KEYはダメ。SPACIALは試してない）だけが暗黙のROW_FORMAT変換が走らない。それ以外は走る。

しかしPKなしのUNIQUE KEY追加ってそれがクラスターキーになるんだけどROW_FORMAT変換は走らないのね。。


テストコードはこちら。mtrスタイルだけどステートメントを上から全部順番に実行すればフツーのmysqlでもいける。

https://gist.github.com/yoku0825/57ba8a8788b792e0ca39


実際、ROW_FORMATの変換によりどの程度の負荷が発生するのやら、簡単なベンチを取ってみる。

mysql> CREATE TABLE t1 (num serial, val varchar(32));
mysql> LOAD DATA INFILE '/var/lib/mysql-files/md5' INTO TABLE t1; -- 容量があんまりなかったので10万件ほど突っ込む

$ while true ; do mysql -e "INSERT INTO d1.t1 (val) VALUES ('dummy')"; done

mysql> ALTER TABLE t1 MODIFY val varchar(64); -- 暗黙のROW_FORMAT変換は走らない
mysql> ALTER TABLE t1 MODIFY val varchar(256); -- 暗黙のROW_FORMAT変換が走る

ちょっとズレがあるけど、ALTER TABLEは変換なしが横軸17のあたり、変換ありが横軸14のあたり（あ、縦軸の単位はbytesです）

変換なしのALTERは10msくらい、変換ありのALTERは100msくらい。rebuild_write（単位はbytes）がハネてるので、やっぱりオンラインはオンラインでもROW_FORMAT変換が走っちゃうと本番ではそれなりに行きそう。


本番では pt-online-schema-change 使ってるからあんま関係なさそうですなんですけどね ;)