MySQL 8.0.14で全件 COUNT(*)でも加速しない！？- 「innodb_parallel_read_threads」検証その３

パーティショニングの話をするつもりだったのですが

いろいろなパーティションを試しながら計測しつつ、そもそもパーティション前の数字ももう一度計測しておこう、と思ったら、今まで加速してたパターンで加速しないケースにぶつかってしまいました。

パラレル化の恩恵が出た（昨日までの）状態；PKのINT AUTO_INCREMENT欠番がそこそこある＋ALTER TABLE ENGINE INNODBしてない。
パラレル化の恩恵が出ない（今日の）状態：PKのINT AUTO_INCREMENT欠番がまったくない＋ALTER TABLE ENGINE INNODBした
この観点でパターン増やさないとまずそう。

— atsuizo (@atsuizo) January 25, 2019

こんな感じです。

環境

「その１」「その２」と基本的には同じですが、データを準備する手順に、「条件」で言及するパターンをもたせています。
バージョンはMySQL8.0.14のみです。

条件

INSERTINTO table_name () VALUES ();
INSERTINTO table_name (itemid) SELECT0FROM table_name; -- 繰り返すたびに倍のレコードが生まれる

検証結果

オプティマイズしたテーブルに対して、全件カウントのパラレル化がほとんど効果を出していませんね。

このパターンを作るのに、ものすごく時間がかかりましたが、平たく言うと「それだけ」でした。。。

しかし、なぜこうなるのか、理屈がわかりません。。。オプティマイズ直後って、キレイなBツリーで格納されているんじゃないの？

まとめ

• 全件カウントは、オプティマイズ（ALTER TABLE table_name ENGINE INNODB」してないほうが、パラレル化の恩恵を受けられる。
• 理由はわからない。。。

AUTO INCREMENTの欠番の件といい、オプティマイズ後のサイズの件といい、今回のパラレル全件検索の件といい、MySQLの中の人に聞きたい。。。

で、次回こそ、パーティショニングへの効果を測りたいと思います。
今回の検証結果を踏まえて、過剰に？オプティマイズしてない状態で試したいと思います。

いや、すでに少し試している感じでは、一応効いているっぽいんだけど。

その他、「こんな観点で違いがあるか見てほしい」というのがあったら、やってみたいと思いますので、ブコメなりツイッターなりSlack（MySQL Casual）なりでリクエスト貰えれば、できるだけチャレンジシてみたいと思います。

詳解MySQL 5.7 止まらぬ進化に乗り遅れないためのテクニカルガイド (NEXT ONE)

• 作者:奥野幹也
• 出版社/メーカー:翔泳社
• 発売日: 2016/08/26
• メディア:単行本（ソフトカバー）
• この商品を含むブログを見る