これは MySQL Advent Calendar 2020 21 日目のエントリです。
昨日は mita2 さんの**「MySQL バイナリログをマスキングするツールを作ってみた」**でした。

そして、↓の記事の続きでもあります。

AWS の EC2 Graviton2 インスタンスに MySQL をインストールしてみた（だけ）

前回はタイトルどおり本当に（R6g インスタンスに）MySQL をインストールしただけでしたので、今回はmysqlslapを使って R5（r5.large）インスタンスと比較してみます。

※mysqlslapの説明は以下のページにあります（使うのは 8.0 用ですが基本は同じ）。

4.5.7 mysqlslap — 負荷エミュレーションクライアント（MySQL 5.6 リファレンスマニュアル）

（いまさらですが、表中の--auto-generate-sql-load-typeの説明が間違っていることに気づきました…クエリ数ではなくて種別ですね。）

準備

Graviton2 インスタンスは前回用意した r6g.large（2vCPU・メモリ 16GiB）をそのまま使い、比較用のインスタンスは r5.large（vCPU 数・メモリ容量同じ）を使い同様の手順で用意しました。

`mysqlslap`実行内容

mysqlslapでは与える負荷の種別を選択できるので、今回は 5 種類全て試しました。

※それ以外に、SQL（文）を直接指定する方法もあります。

(1) mixed（混合）

mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=mixed -u root -p

(2) read（テーブルスキャン）

mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=read -u root -p

(3) key（主キーで読み取り）

mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=key -u root -p

(4) write（挿入）

mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=write -u root -p

(5) update（主キーで更新）

mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=update -u root -p

結果

インスタンスタイプ	(1) mixed	(2) read	(3) key	(4) write	(5) update
r6g.large (a)	38.958	113.818	22.365	55.131	57.179
r5.large (b)	47.390	143.640	30.545	61.441	68.535
(b) / (a)	1.22	1.26	1.37	1.11	1.20

※数値は 3 回実行した平均。単位は秒。

やはり、Intel のプロセッサよりもメモリアクセスや I/O が高速、という特性が出ているのでしょうか？

読み取り系（read・key）はバッファプールに載っているデータの読み取りが中心
- 前者がシーケンシャルな読み取り、後者がランダム読み取り
writeは EBS（gp3）へのシーケンシャルな書き込みが中心
- binlog・Redo log など
- 並行してバッファプール（メモリ）を読み書き
mixed・updateはそれらの混合
- mixedのほうが読み取り比率が高め

と考えると大体のイメージが掴めそうです（と、思いました。この段階では）。

ところが…

innodb_log_writer_threadsの検証を兼ねて、さらにコア数の多いインスタンスで負荷を上げていったところ、予想とはちょっと違う方向に…？

※MySQL Advent Calendar 2020 23 日目のエントリに続きます。

MySQL 8.0.22 で innodb_log_writer_threads の効果を見てみる

明日（22 日目）は **atsuizo さん**です。

Qiitaに投稿したMySQL 8.0関連記事
MySQL 8.0 の薄い本（無料で配布中！）