みなさん、こんにちは。

データテーブル内のレコードをカウントするとき、カウント関数を使用してカウントすることに慣れていますが、カウント関数に渡すことができるパラメータには、 count(1) 、 count() 、 count(column) など、さまざまな種類があります。 …

それで、どれが最も効果的ですか？count(*) は最も効率が悪いのではないでしょうか?

count(*) は最も効率が低いと考えられ、クエリのようにテーブル内のすべてのフィールドを読み取るものと想定されることがよくありますSELECT * FROM。これは本当ですか? 以下で調べてみましょう。

1. どの count ステートメントが最高のパフォーマンスを発揮しますか?

前回の結論から始めます。

coun(*) = count(1) > count(primary key column) > count(column)

これを理解するには、count() 関数の動作原理をさらに深く掘り下げる必要があります。次に進む前に、記事の内容について同意しましょう。

データベース: MySQL
ストアエンジン: InnoDB

1.1. count()とは何ですか?

Count(arg) は集計関数であり、count() 関数のパラメータは列、定数、または偶数 (*) です。この関数は、クエリ条件を満たすレコードの数をカウントするために使用され、count(arg) 関数のパラメータには異なる値が指定されていますnull。count 関数の引数が次のようなフィールドであるとします。

select count(name) from member;

このステートメントは、以外の名前フィールドを持つメンバーテーブル内のレコードの数をカウントしますnull。つまり、レコードの名前フィールドの値がの場合null、カウントされません。次のように、count() 関数のパラメーターが定数 1 であると仮定します。

select count(1) from member;

もちろん 1 は常に異なるnullため、上記のステートメントはメンバーテーブルにレコードがいくつあるかをカウントします。より深く理解するために、count 関数の操作メカニズムと実行戦略について学びましょう。

1.2. Count(主キー)はどのように機能しますか?

count(arg) 関数を使用してレコードの数をカウントすると、MySQL は count という変数を保持し、1 回のパスでレコードを読み取ります。count 関数の arg 値がと異なる場合null、すべてのレコードが参照されるまで count 変数に 1 を追加し、その後ループを終了します。最後に、count 変数の値をクライアントに返します。

ご存知のとおり、インデックスにはクラスター化インデックスとセカンダリインデックスの 2 種類があります。それらの違いは、クラスター化インデックスのリーフノードは実際のデータを保存するのに対し、セカンダリインデックスのリーフノードはレコードのデータではなく主キー値のみを保存することです。デフォルトでは、主キーを作成するとクラスター化インデックスが自動的に作成され、InnoDB は B+ ツリーのリーフノードにレコードを保存します。

例として次のコマンドを取り上げます。

select count(CardNo) from member;

テーブルにクラスター化インデックスのみがあり、2 番目のインデックスがない場合、InnoDB はクラスター化インデックスを参照します。InnoDB はレコードごとに主キー値を読み取り、比較しますnull。異なる場合はnullcount 変数に 1 を加算します。

別の例Phone_Noとしては、主キーがあり、(Phone_No, Name)テーブル内に2 番目のインデックスが存在しますMember。

ただし、テーブルにセカンダリインデックスがある場合、InnoDB はクラスター化インデックスではなくセカンダリインデックスを参照します。その理由は、セカンダリインデックスが占めるストレージ領域がクラスター化インデックスよりも少ないためです => セカンダリインデックスツリーがクラスター化インデックスツリーよりも小さい => 2 番目のインデックスをスキャンする場合の I/O コストがクラスター化インデックスをスキャンするよりも低いためです。したがって、オプティマイザはセカンダリインデックスの使用を優先します。

1.3. Count(1) はどのように機能しますか?

count 関数のパラメーターは 1 ですが、これは明らかに列ではなく、列でもありませんnull。それで、count(1)それはどのように機能するのでしょうか？

例えば：

select count(1) from member;

クラスター化インデックスのみでセカンダリインデックスがない場合、InnoDB はクラスター化インデックスを参照してレコードをカウントしますが、主キーの値を読み取ることなく、レコードのみを参照します。レコードの有無が異なるとみなされるためnull。

比較するためにレコード値を読み取る必要がないため、 Count(1)処理が高速になることがわかります。ただし、テーブルにセカンダリインデックスがある場合、InnoDB は最初にセカンダリインデックスを参照します。 Count(primary key column)null

1.4. Count(*) はどのように機能しますか?

* 文字を見ると、レコード内のすべてのフィールド値が読み取られていると思いますか?

の場合は true になりますselect *が、そうでcount(*)ない場合は成立しません。 を呼び出すとcount(*)、MySQL はパラメータをに変換しますcount(0)。

したがって、count(*) の実装は count(1) と同一であり、パフォーマンスの違いはありません。

1.5. count(列)はどのように機能しますか?

次のような例があります。

select count(name) from member;

このクエリでは、MySQL はテーブル全体をスキャンしてカウントするため、Count(column) は count(1)、count(*)、および count(primary key columns) と比較して最もパフォーマンスが悪くなります。

列にセカンダリインデックスがある場合、コマンドはそのインデックスを使用して参照するため、速度が向上します。

1.6. まとめ

coun(*) = count(1) > count(primary key column) > count(column)

coun(*)またはを使用することをお勧めしますcount(1)。

テーブルにセカンダリインデックスがある場合、InnoDB は参照するセカンダリインデックスを選択します。プライマリインデックスを参照するよりも効率的であるためです。

上記に 2 番目のインデックスがない場合は、テーブル全体をスキャンする可能性があるため、レコード数のカウントにはcolumn X使用しないでください=> 最も効果的ではありません。Count(column X)

2. その他の場合のカウント

2.1. Storage Engine は count(*) とどう違うのですか?

なぜ count() 関数がレコードを反復処理する必要があるのか疑問に思われるかもしれません。

記事の冒頭では InnoDB ストレージエンジンについてのみ説明しましたが、ストレージエンジンが異なれば count 関数の実装方法も異なる場合があります。たとえば、別の MySQL ストレージエンジンである MyISAM は、InnoDB に次いで 2 番目に人気があります。

MyISAM を使用する場合、各テーブルには値を含むメタデータが含まれますrow_count。したがって、テーブル内のすべてのレコードをカウントするrow_count必要がある場合(フィルター条件なしで count())、MyISAM はO(1) 複雑度で値を読み取るだけで済みます。

count() にフィルター条件がある場合、MyISAM と InnoDB の動作は変わりません。どちらもテーブルをスキャンして、一致するレコードの数を数える必要があります。

* を読み取るときrow_count、MyISAM はこの値の一貫性を確保するためにテーブルをロックすることに注意してください。