mysqlクエリの最適化

MySQL クエリで、特定のフィールド packageId (主キーではない) = num の結果をフィルターで除外するには、not in を直接使用するか、クエリが完了して結果セットが走査されたときにフィルターで除外する方がよいでしょうか。クエリが完了したら、何があっても結果セットを走査する必要があります。

返信内容:

MySQL クエリで、特定のフィールド packageId (主キーではない) = num の結果をフィルターで除外するには、not in を直接使用するか、クエリが完了して結果セットが走査されたときにフィルターで除外する方がよいでしょうか。クエリが完了したら、何があっても結果セットを走査する必要があります。

件名がコメントに質問を追加しました

インデックスのみを考慮しているため、<> のようなクエリ条件ではインデックスが使用されず、テーブル全体のクエリ速度が非常に遅くなることが考えられます。ただし、このタスクのデータ量は依然として非常に大きいです。 Webサイトの一部のパッケージ利用者にテキストメッセージによるリマインダーを送信する機能です。このパッケージは無料で提供され、考慮されないため、これは 7 に等しくありません。したがって、それを削除する必要があります。

大量のデータを含むこの種の完全なテーブルの走査の場合、まず、テーブル全体を取得するこの方法はお勧めできません。たとえば、id をクエリする場合、主キー ID セグメントの形式でクエリを実行することを検討できます。初めて 200 レコードを超える 0 を記録し、その後、現在の最大 ID を 200 レコードを超えるクエリを実行します

この種の ID セグメンテーションのシナリオでは、packageId をクエリ条件に安全に含めることができます。これは、主キー ID に移動する必要があるためです。そのため、mysql によってフィルタリングされたデータは最大でも 200 件のみなので、それほど大きなものではありません(200 は単なる例であり、実際の状況とサービスの圧力に応じて制御できます)

追加の利点は、現在のタスクの進行状況をリアルタイムで観察できることです (200 人のユーザーが送信された場合はログに記録でき、タスクが中断された場合はどこから始めるべきかもわかります)

---

==== 元の答えは次のとおりです ===

クエリにはページングがないため、実際にはデータの量が非常に少ないと考えられます。ページングがないため、必然的に SQL クエリ中に完全なテーブル スキャンが行われます。大きな違いはありません
さらに、値と等しくないだけなので、より直感的に使用できます!=

クエリに大量のデータがある場合、または実際にページングが含まれている場合 (ただし、ここにあるデモ コードはまだ作成されていません)、クエリを支援する他のインデックス付きクエリ条件があるかどうかを検討する必要があります。データがない場合は、この packageId にインデックスを追加するかどうかを検討する必要があります (packageId の分布がこのテーブル内に十分に分散している場合)

リーリー

直接使用<>

最初の方が速いです。
Mysql のクエリ速度は、トラバース速度よりもはるかに高速です。トラバース時の反復回数は少ないほど良いです。

データをすべて持ち出さないでください。 。 。 mysqlはそれを我慢できません