今回はinnodbにおけるcountの高速化について検証する。きっかけは下記のブログですが。いつもお世話になっております。t1;このとき例えばtinyintなどにindexを貼ることで、count(*)の高速化が見込める。innodbのcount(*)において全レコードへのアクセスが必要になることは変わりないがこれは主キー(bigint)を全走査することよりも、小さいindexを全走査するほうが効率が良いということである。頭のなかでは理解できて、予想はできているんだけどちゃんと自分の手でピコピコやりたいなというところで下記を確認する。検証2のリーフノードの大きさの検証のため下記データベースを用意する。値同じだけ今回はcountなので影響なし。検索するまずは2.について。リーフノードのデカさは検索性能に影響するのか。予想ではしないと思う。B木のキーノードだけ走査するわけだから。sec)!驚愕である。リーフノードの大きさが検索性能に大きく依存しているではないか。これについてはもっと深追いして理解する必要がありそうだ。sec)あんまりintと変わらない。これも参考元にある通り。内部的には読み込みページとかの量が半減しているはずである。予想外の挙動を見せたクラスタインデックスの違いはなんだろうか。CHARSET=utf8;これに対してデータを1000万件投入する。sec)リーフノードのデータ量が検索速度に影響を及ぼす可能性を検証するためにカラムgを空文字にupdateして検証する。sec)なんと!高速化されたではないか。今までcount(*)するときにindexのキーだけなめて検索しているのかと思っていた。(これはcount(id)でも計測時間が変わらなかったことからの推測でもある)しかしこの結果から導かれるのは、count(*)したときにリーフノードのデータを読み取っているということにほかならないのではないかと。B木インデックスってのはB木のキーと値を全部読み取るような振る舞いをしている。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。count(*)からinnodbにおけるindex構成を確認するdatabaseチューニングlinux上での時間についてmacのtopコマンドを追うRECOMMENDこちらの記事も人気です。