22

状況は次のとおりです。

  1. 最初にクエリを実行して、存在するレコードの数を知る必要があります。

    例えば：SELECT COUNT(DISTINCT userid) from users;

  2. 多くの場合、必要なのはこれだけです。ただし、場合によっては (たとえば 30% の確率で) 最初のクエリに続いて、レコードの詳細を示す 2 番目のクエリを実行したい場合があります。

    例えば：SELECT * FROM users;

SELECT COUNTただの代わりに最初に実行する理由はありますSELECTか? つまり、実際にレコードをプルバックするよりも、SQL でレコードのカウントを行う方が速いのでしょうか? それとも、どちらの方法でも本質的に同じ作業を行っているので、2 つのクエリを実行することは避けるべきですか?

言い換えれば、常に最初のクエリでレコードを取得し ( を使用しないCOUNT)、コードでレコードをカウントする (Java) 方が良いでしょうか。ユーザーが 2 番目のクエリを実行したい場合は、データが既にあります。そうでない場合は、ダンプしてください。

ここでのベストプラクティスは何ですか?

4

4 に答える 4

26

データが必要であることがわかっている場合は、先に進んでデータを取得し、コードで数えます。ただし、カウントのみが必要な場合は、実際に行を取得するよりも、データベースからカウントを取得する方がはるかに高速です。また、必要なものだけをプルするのも標準的な方法です。

たとえば、テーブル内のすべての行をカウントしている場合、ほとんどのデータベース実装では行を確認する必要はありません。テーブルは、いくつの行があるかを知っています。クエリの句にフィルターがありwhere、インデックスを使用できる場合、実際の行のデータを確認する必要はなく、インデックスから行をカウントするだけです。

そして、これはすべて、転送されるデータが少ないことを考慮していません。

データベースの速度に関する経験則は、先に進んで自分で試してみることです. 一般的なルールは常に良い指標とは限りません。たとえば、テーブルが 10 行で数列しかない場合、データベースへの 2 回の往復がクエリのコストを上回るため、必要に応じてすべてを取得することもできます。

于 2013-04-09T21:26:49.727 に答える
2

次の理由により高速です。

  • データベースは、そのようなことを可能な限り高速にするように設計および作成されています。
  • テーブル全体をアプリケーションに送信する必要はありません。代わりに整数を 1 つだけ使用します。

テーブル全体を送信してアプリケーション側をカウントしないでください。

于 2013-04-09T21:25:12.290 に答える
0

ただの個人的な意見:

count()「詳細な」クエリが 100% のケースで必要ない場合は、MySQLの機能を使用するのが理にかなっています。より高速で安価です。MySQL は、大量のデータを送信してレコードセットを走査し、行をカウントするという「重い」タスクをアプリに任せるのではなく、「重い」カウント タスクを実行し、データの小さなチャンクを送信します。

とはいえ、通常のヒント: テーブルが適切にインデックス化されていることを確認して、クエリが最適に実行されるようにします。

于 2013-04-09T21:25:21.797 に答える