MySQLのCOUNT(*)のパフォーマンスについてお話しましょう

序文

基本的に、職場のプログラマーは、count(*)、count(1)、または count(primary key) を使用して、データベーステーブルの行数をカウントします。これらの違いとパフォーマンスを理解していますか?

実際、開発プロセス中に、プログラマーが大きなテーブル内の行の総数を数えることは、非常に時間のかかる作業です。では、より速く数えるにはどの方法を使用すればよいでしょうか?

次に、MySQL で総行数をカウントする方法とパフォーマンスについて説明します。

count(*)、count(1)、count(主キー)のうちどれが速いでしょうか?

1. テーブルを作成し、実験テスト用に 1,000 万件のレコードを挿入します。

# テストテーブルを作成する CREATE TABLE `t6` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(50) NOT NULL,
 `status` tinyint(4) NOT NULL、
 主キー (`id`)、
 キー `idx_status` (`status`)
)ENGINE=InnoDB デフォルト文字セット=utf8;

# 1000w データを挿入するストアド プロシージャを作成する CREATE PROCEDURE insert_1000w()
始める
  i INT を宣言します。
  i=1 を設定します。
  i<=10000000の場合
    t6(name,status) に VALUES('god-jiang-666',1) を挿入します。
    i=i+1 を設定します。
  終了しながら;
終わり;

#ストアド プロシージャを呼び出して 1,000 万行のデータを挿入します。call insert_1000w();

2. 実験結果を分析する

# 0.572秒かかりました select count(*) from t6;

ここに画像の説明を挿入

# 0.572秒かかりました select count(1) from t6;

ここに画像の説明を挿入

# 0.580秒かかりました select count(id) from t6;

ここに画像の説明を挿入

# 0.620秒かかりました select count(*) from t6 force index (primary);

ここに画像の説明を挿入

上記の実験から、 count(*) と count(1) が最も速く、次に count(id) が続き、count が必須の主キーを使用する場合に最も遅いことがわかります。

それぞれの実行プランをテストし続けましょう。

select count(*) from t6; を説明します。
警告を表示します。

ここに画像の説明を挿入

t6からcount(1)を選択することを説明する。
警告を表示します。

ここに画像の説明を挿入

t6からcount(id)を選択する方法を説明します。
警告を表示します。

ここに画像の説明を挿入

select count(*) from t6 force index (primary); を説明します。
警告を表示します。

ここに画像の説明を挿入

上記の実験から、次の 3 つの点がわかります。

MySQL クエリオプティマイザーは count(*) を count(0) に書き換え、idx_status インデックスを選択します。
count(1)とcount(id)はどちらもidx_statuxインデックスを選択します。
フォースインデックス（プライマリ）を追加した後、強制インデックスが使用されます。

この idx_status は、セカンダリ補助インデックスツリーに相当します。その目的は、InnoDB が count(*) を処理するときに、補助インデックスツリーがある場合は、補助インデックスツリーを優先して行の総数をカウントすることを示すことです。

count(*) が補助インデックスツリーを優先するという結論を確認するために、次の実験を続けましょう。

# idx_statusインデックスを削除し、count(*)の実行を続行します。
テーブル t6 を変更してインデックス idx_status を削除します。

select count(*) from t6; を説明します。

ここに画像の説明を挿入

上記の実験から、補助インデックスツリー idx_status が削除された場合、count(*) は主キーインデックスの使用を選択することがわかります。結論としては、 count(*) は補助インデックスを優先します。補助インデックスがない場合は、主キーインデックスが使用されます。

count(*) がセカンダリインデックスを優先するのはなぜですか?

MySQL 5.7.18 より前では、InnoDB はクラスター化インデックスをスキャンして count(*) ステートメントを処理していました。

MySQL 5.7.18 以降、InnoDB は利用可能な最小のセカンダリインデックスをトラバースして COUNT(*) ステートメントを処理します。セカンダリインデックスが存在しない場合は、クラスター化インデックスがスキャンされます。

新しいバージョンでは、count(*) の処理にセカンダリインデックスが使用されるのはなぜですか?

InnoDB セカンダリインデックスツリーのリーフノードには主キーが格納され、主キーインデックスツリーのリーフノードにはデータの行全体が格納されるため、セカンダリインデックスツリーは主キーインデックスツリーよりも小さくなります。したがって、クエリオプティマイザーはコストを考慮してセカンダリインデックスを優先します。したがって、インデックス count(*) は count(主キー) よりも高速です。

要約する

この記事の結論はcount(*)=count(1)>count(id)です。

主キーインデックスがないと count(id) が遅くなるのはなぜですか? count(id) は主キーを取得し、それが空かどうかを確認してから累積する必要があるため、コストが高くなります。

Count(*) はすべての NOT NULL および NULL フィールドをカウントしますが、count(id) は NULL フィールドをカウントしません。そのため、テーブルを構築するときは NOT NULL を使用し、デフォルトを空にするようにする必要があります。

最後に、将来的にデータベーステーブルの行数を合計したい場合は、count(*) または count(1) を大胆に使用できます。

参考文献