MySQLのCOUNT文-count（*）、カウント（定数）は、COUNT（列名）
私は、人々はしばしば、すべてのプログラマで笑う、多くの人が精通していないと信じて、データベースクエリCRUDコミッショナーで、このいわゆるCRUDは、検索データベースを変更するために追加や削除を指します。
追加および削除がデータベース操作を検索変更するには、最も頻繁に使用されるクエリです。すべてのクエリー操作では、統計的な操作の数が使用されることが多いです。
データベース内の行数に関する統計、MySQLやOracleのいずれかで、使用可能な機能を持っている、つまり、COUNT
しかし、特にインタビューの中で、それが悪用されるだろうと信じて、この共通のCOUNT関数ですが、謎の多くを隠されました。以下、次の質問にお答えしようとすると、それを信じてはいけません。
1、いくつかの用途があるCOUNT？
2、COUNT（フィールド名）とCOUNT（*）クエリの結果何が違いますの？
3.（1）およびCOUNT（*）COUNTの違いは何ですか？
4、効率の間（*）COUNT（1）とCOUNTより高いですか？
5.「マニュアルアリババのJava開発」COUNT（*）を使用することをお勧めしますなぜ
6、COUNT（*）のためのMySQLのMyISAMのエンジンは何をするために最適化？
7、COUNT（*）のためのMySQLのInnoDBエンジンは何をするために最適化？
8は、上記COUNT（*）上のMySQLが行うことに最適化され、どのような重要な前提であることはつまり？
9、SELECT COUNT（*）と、プラス差がある条件なし？
10、（1）とCOUNT（フィールド名）実行COUNT（*）で、何をCOUNT？
以上の10件の質問、あなたがすべて正確に答えることができれば、それはあなたが本当にCOUNT関数を理解すること、そしてどのような知識を理解していないがある場合は、この記事では、あなただけの質問に答えることができます。
1、COUNTを知っています
COUNT関数について、MySQLの公式ウェブサイトで詳しく説明されています。
簡単な翻訳本：
図1は、COUNT（expr）は、値を取得するためにSELECT文は、exprの行がNULLの数ではない戻りました。結果はBIGINT値です。
クエリ結果は、すべてのレコードをヒットしなかった場合は2、0を返します。
図3は、しかし、それはその統計COUNT（*）、NULL値を含む行の数を注目に値します。
create table t_count(id int,id2 int);
insert into t_count values(null,null);
insert into t_count values(1,null);
insert into t_count values(null,1);
insert into t_count values(1,null);
insert into t_count values(null,1);
insert into t_count values(1,null);
insert into t_count values(null,null);
select count(*),count(id),count(id2),count(1) from t_count;
以下のテーブルのレコードその
root@localhost[lhrdb]> create table t_count(id int,id2 int);
Query OK, 0 rows affected (0.36 sec)
root@localhost[lhrdb]> insert into t_count values(null,null);
Query OK, 1 row affected (0.07 sec)
root@localhost[lhrdb]> insert into t_count values(1,null);
Query OK, 1 row affected (0.06 sec)
root@localhost[lhrdb]> insert into t_count values(null,1);
Query OK, 1 row affected (0.08 sec)
root@localhost[lhrdb]> insert into t_count values(1,null);
Query OK, 1 row affected (0.03 sec)
root@localhost[lhrdb]> insert into t_count values(null,1);
Query OK, 1 row affected (0.05 sec)
root@localhost[lhrdb]> insert into t_count values(1,null);
Query OK, 1 row affected (0.03 sec)
root@localhost[lhrdb]> insert into t_count values(null,null);
Query OK, 1 row affected (0.08 sec)
root@localhost[lhrdb]>
root@localhost[lhrdb]> select * from t_count;
+------+------+
| id | id2 |
+------+------+
| NULL | NULL |
| 1 | NULL |
| NULL | 1 |
| 1 | NULL |
| NULL | 1 |
| 1 | NULL |
| NULL | NULL |
+------+------+
7 rows in set (0.00 sec)
use文数（*）、数（ID）、カウント（ID2）は、次のようにクエリの結果は次のとおりです。
root@localhost[lhrdb]> select count(*),count(id),count(id2),count(1),count(2) from t_count;
+----------+-----------+------------+----------+----------+
| count(*) | count(id) | count(id2) | count(1) | count(2) |
+----------+-----------+------------+----------+----------+
| 7 | 3 | 2 | 7 | 7 |
+----------+-----------+------------+----------+----------+
1 row in set (0.00 sec)
また、（ID）及び（COUNT COUNTする行数をカウントするために外に）、あなたはまた、COUNTを使用することができます（定数）（COUNTは、（1）のような）、そして3つのSQLステートメントは、それがどのような違いを生むのでしょうか？最終的にはどちらがより効率的ですか？「マニュアルアリババJavaの開発」（COUNTを置き換えるためにCOUNT（列名）またはCOUNT（定数）を使用しないよう義務付けなぜ）か？
（*）COUNT（列名）、COUNT（定数）と数との差
に述べた以前のCOUNT（expr）は統計を作成するために使用される行の数は、統計はexpr中の行の数がNULLでない場合、次いで、COUNT（カラム名）、COUNT（定数）とCOUNT（*）3つの構文、exprが列名、定数、および*です。
その後、カラム名は、定数は、と*の3つの条件、定数は確かに、NULL、固定値ではありません。*クエリは、行全体として理解することができ、それは確かにNULLでない場合、唯一のクエリ結果の列名はNULLである可能性が高いです。
だから、COUNT（定数）とCOUNT（*）は、クエリを直接修飾されたデータベーステーブルの行数を示します。COUNT（列名）は、クエリが列の値の資格表す行の数のNULLではありません。
異なる照会結果セットに加えて、COUNT（ ）と比較COUNT（定数）とCOUNT（列名）が懸念され、COUNT（ ）、彼は標準の構文であるため、構文は、MySQLので、行SQL92標準的な統計の定義の数ですたくさんの最適化のためのデータベース、彼を。
SQL92、ANSI / ISO標準のデータベース。これは、言語（SQL）データベースと行動（トランザクションの分離レベル、など）を定義します。
最適化のCOUNT（*）がされている
以前のCOUNT（*）を言及した最適化の多くは、彼に対するMySQLデータベースので、行SQL92標準的な統計の定義の数の構文です。だから、何が特定のものはそれをやっていますか？
異なる実行エンジンを区別するためにここに提示しました。MySQLのより一般的に使用される実行エンジンはInnoDBテーブルとMyISAMテーブルです。
そこのMyISAMとの重要な違いがあり、私たちは、MyISAMテーブルレベルロックがロックしているトランザクションをサポートしていないことのMyISAMに関連するCOUNT（*）を導入しようとしているInnoDBは、多くの違いがあり、そしてInnoDBがサポートラインをトランザクションをサポートし、レベル・ロック。
MyISAMテーブルロックは、テーブルレベルのロックなので、操作上のシリアル同じテーブルを必要とするので、MyISAMテーブルは、テーブルの数から使用した場合、単純な最適化は、それが別々に記録されたテーブル内の行の数を置くことができるということであるたため（*）クエリ時間は、記録された値に直接返すことができ、もちろん、前提がどこな条件ではないことができます。
MyISAMテーブルのデータベース・テーブル・レベル・ロックは、同時データベース行の数を変更する必要がないので、テーブル内の行の総数は（*）クエリで使用カウントに記録することができる理由のMyISAM理由は、それがあるので、クエリから得られる行数が正確です。
InnoDBはほとんどの操作は、行レベルのロックなので、テーブル内の行の数は、同時変更であってもよいし、行の数が記録され、キャッシュされてもよい、トランザクションをサポートするためしかし、InnoDBは、キャッシュがこの操作を行うことはできませんそれは正確ではありません。
しかし、InnoDBのか、COUNT（*）文には、いくつかの最適化を行いました。
InnoDB内で、COUNT（*）表は、スイープを行うことが避けられない場合、行のクエリ数を使用して、その後、プロセステーブルを掃引するための努力の効率を最適化することができます。
MySQLの8.0.13から始まって、SELECTテーブルを掃引する過程でいくつかの最適化をしました、InnoDBの者（*）tbl_nameをステートメントのFROMをCOUNT。クエリがGROUP BYまたは条件が含まれていないことを条件とします。
彼は、その後、プロセス内のテーブルを掃除低コストのインデックスを選択することができますので、もし彼が、見つけ、自分の特定の値を気にしないように私たちは、COUNT（*）は、行の統計数を対象とし、知っていますそれが大幅に時間を節約することができます。
私たちは知っている、クラスタ化インデックス（主キーインデックス）と、非クラスタ化インデックス（非プライマリキーインデックス）へのInnoDBインデックス、保存されたリーフノードクラスタ化インデックスは、クラスタ化インデックスのリーフ・ノードは、保存するのではなく、全体の行です主キー列の値です。
MySQLは、テーブルを掃除するために最低限の非クラスタ化インデックスを優先させて頂きますのでので、非クラスタ化インデックスに比べて、クラスタ化インデックスよりもはるかに小さいです。我々は、テーブルを建てたときにそう、主キー索引に加えて、非プライマリキーのインデックスを作成することが必要です。
これまでのところ、我々はWHEREとGROUP BY条件が含まれていないクエリの最適化の前提であるCOUNT（*）、のためのMySQLデータベースの最適化を介して導入しています。
COUNT（*）とCOUNT（1）は
、オンラインで異なる意見を言って、最後に2つの間に違いはありませんそのため、その後COUNT（*）、（1）COUNTを見て、上に導入しました。
いくつかの前記COUNT（*）は、COUNTに変換される（1）が実行されるので、それほど速くCOUNTは、（1）より少ない変換ステップ、。
一部では、MySQLのCOUNTについて（ので、と述べている最適化された特殊なので、COUNTを（やって）速いです）。
だから、最終的にどのステートメントが正しいのですか？MySQLの公式文書を見てすることは言う方法です。
InnoDBはSELECT COUNT（*）およびSELECT COUNT（1）同様に操作を処理します。何のパフォーマンスの違いはありません。
絵画のキー：同じように、ないパフォーマンスの違い。したがって、COUNT（1）およびCOUNT（*）は、MySQLの最適化は存在しない他の誰よりも早く、まったく同じです！
それによって推奨されているように、COUNT（*）とCOUNT（1）されていますか？
推奨COUNT（*）！これがあるので行数の構文は、標準的な統計の定義をSQL92、これはOracleだけでは、この問題、それのまた別の意見の分析を行うためのMySQLをベースにしています。
COUNT（フィールド）
最後に、我々はまだ彼のクエリを言及していないCOUNT（フィールド）があり、比較的単純で、粗で、全表スキャンで、その後、指定したフィールドの値がNULLとしてではない決定、NULLは累積的ではありません。
比較するとCOUNT（ ）、COUNT（フィールド）一歩は、クエリのフィールドがNULLであるかどうかを判断するので、COUNTよりも彼のパフォーマンス（）が遅いです。
まとめ
この記事では主に、テーブルの行数のために、COUNT関数の使用を記載しています。主な用途は、COUNT（*）、COUNT（フィールド）とCOUNT（1）です。
COUNT（ので）構文は、統計行SQL92定義の標準数であるので、彼は、MySQLの最適化の多くを持っていた、MyISAMテーブルは別途COUNT（のために記録されたテーブルの行数に直接になります）クエリ、InnoDBはテーブルに掃引します最小のインデックスを選択する際のコストを削減します。もちろん、これらの最適化の前提はどこのグループ条件との問い合わせではありません。
InnoDB COUNT（*）およびCOUNT（1）の差、及び同じ効率に実装されていないが、効率が低くなるので、COUNT（フィールド）フィールドは、非NULLの決意を必要とします。
COUNT（ので）構文は行数SQL92標準的な統計の定義、および高効率であるため、COUNT（お使いくださいテーブル内の行の）問い合わせ番号を！
参考文献：
https://dev.mysql.com/doc/refman/8.0/en/group-by-functions.html#function_count
私について
------------------------------------------
●著者：小麦の苗侵害お問い合わせください小麦の苗を削除する場合は、ネットワークからの仕上げの部分
（●のitpub紙、ブログの庭、CSDNと個人的なマイクロチャネル公共数xiaomaimiaolhrに持っている）、同期更新
●この記事のitpubアドレス：http://blog.itpub.net / 26736162
この記事のブログパークアドレス●：http://www.cnblogs.com/lhrbest
この記事CSDNアドレス●：https://blog.csdn.net/lihuarongaini
●この記事、個人のプロファイルとウィートグラスクラウドディスクアドレスのPDF版：HTTP ：//blog.itpub.net/26736162/viewspace-1624453/の
●データベース筆記試験と面接の回答：http://blog.itpub.net/26736162/viewspace-2134706/
アドレス帳にDBA●今日のヘッドライン：HTTP：/ /www.toutiao.com/c/user/6401772890/#mid=1564638659405826
--------------------------------- ---------
●QQグループ番号：230 161 599 618 766 405
●マイクロチャネルグループ：缶 Iマイクロ手紙、私はあなたが一つであり、グループに皆を引っ張ります
●私はQQの友人（646 634 621）を追加してください連絡し、追加の理由は言及
西安に完成2019年10月31日24:00 - 2019年10月1日06:00●を
2019年10月1日午前6時：最後に変更されました● 2019年10月31日24:00〜
小麦の苗の研究ノートから派生●記事内容、ネットワークからのいくつかの並べ替え、もし侵害または不適切のでご了承ください
●著作権を、この記事を共有してください、ソースを保管してください再現
--- ---------------------------------------
●小麦の苗マイクロストア：https://weidian.com/s/793741433?wfr=c&ifr=shopdetail
●小麦の苗シリーズパブリッシュされたデータベースのカテゴリ：http://blog.itpub.net/26736162/viewspace-2142121/
●小麦の苗OCP、OCM、高可用性ネットワーククラス：http://blog.itpub.net/26736162/viewspace-2148098/
●小麦の苗テンセント大学のホームページ：Https://lhr.ke.qq.com/
------------------------------------- -----
マイクロチャネルクライアントは、小麦苗の上にマイクロチャネルパブリック番号（焦点を当てるには、以下のQRコードをスキャン使用xiaomaimiaolhr）
、およびQQグループ（DBA帳）小麦の苗のマイクロ文字を追加し、最も実用的なデータベース技術を学びます。
------------------------------------------
