よくある誤解
count(1) と count(primary_key) は count(*) よりも優れています
多くの人は、数を数えるために count の代わりに count(1) と count(primary_key) を使用します(*) の方がパフォーマンスが良いと考えられていますが、実際にはこれは誤解です。一部のシナリオでは、データベースが count(*) カウント操作に対して特別な最適化を行っているため、パフォーマンスが低下する可能性があります。
count(column)とcount(*)は同じです
この誤解は多くの上級エンジニアやDBAの間でもよく見られ、多くの人がそれを当然と思っています。実際、count(column) と count(*) はまったく異なる演算であり、まったく異なる意味を持ちます。
count(column) は、列フィールドが空ではない結果セット内のレコードの数を意味します。
select a,b 結果セット全体に存在するレコードの数を意味します。 from ... は select a ,b,c from... よりも優れており、データベースがより少量のデータにアクセスできるようになります この誤解は主に多くの開発者の間に存在します。主な理由は、開発者がそれを知らないことです。データベースのストレージ原則について詳しく説明します。
実際、ほとんどのリレーショナル データベースは行に格納され、データ アクセス操作は固定サイズの IO ユニット (ブロックまたはページと呼ばれる) (通常は 4KB) に基づいて行われます。ほとんどの場合、複数の行が に格納されます。各 IO ユニットと各行には、その行のすべてのフィールドが格納されます (lob などの特殊なタイプのフィールドを除く)。
つまり、1 つのフィールドを取得するか複数のフィールドを取得するかに関係なく、データベースがテーブル内でアクセスする必要があるデータの量は実際には同じです。
もちろん、例外もあります。つまり、クエリはインデックス内で完了できます。つまり、2 つのフィールド a と b のみがフェッチされる場合、テーブルを返す必要はなく、フィールド c は返されます。使用されているインデックスにない場合は、テーブルに戻ってデータを取得する必要があります。この場合、両者の IO 量は大きく異なります。
order by には並べ替え操作が必要です 必要なデータがインデックスと同じ順序であり、クエリが実行された場合、インデックスデータが実際に順序付けされていることがわかりますの場合、データベースはデータがすでに並べ替えのニーズを満たしていることを認識しているため、通常、並べ替え操作を省略してデータを直接返します。
実際、ソート要件を伴う SQL を最適化するためにインデックスを使用することは、非常に重要な最適化方法です
参考文献: MySQL ORDER BY の実装の分析、MySQL における GROUP BY の基本実装原理、および MySQL の基本実装原理これら 3 つを区別してください この記事、特に最初の記事には、より詳細な分析があります
実行計画に filesort が含まれている場合、ディスク ファイルは並べ替えられます 実際、この誤解は私たちのせいではありませんが、MySQL の開発が原因です。作者の表現に問題があります。 filesort は、Explain コマンドを使用して SQL の実行計画を表示するときに、「追加」列に表示される情報です。
実際、SQL ステートメントでソート操作が必要な場合は常に、「Using filesort」と表示されますが、これはファイルのソート操作が行われることを意味するものではありません。
詳細な資料: MySQL Explain コマンドの出力での filesort について、ここで詳しく説明しています
可能な限り結合を少なくする MySQL の利点はシンプルさです, しかし、これは実はいくつかの面でデメリットでもあります。 MySQL オプティマイザーは非常に効率的ですが、統計情報の量が限られているため、オプティマイザーの作業プロセスに逸脱が発生する可能性が高くなります。複雑な複数テーブルの結合については、オプティマイザーが限られているため、また、結合に対する取り組みが不十分であるため、パフォーマンスは依然として Oracle などのリレーショナル データベースの前任者に比べてはるかに遅れています。ただし、単純な単一テーブル クエリの場合、この差は非常に小さくなり、シナリオによってはこれらの以前のデータベースよりも優れていることもあります。
ソートをできるだけ少なくする ソート操作はより多くの CPU リソースを消費するため、ソートを減らすと、キャッシュ ヒット率が高く、十分な IO 機能があるシナリオでは SQL の応答時間に大きな影響を与える可能性があります。
MySQL の場合、ソートを減らす方法は次のとおりたくさんあります。
上記の誤解は、インデックスを使用してソートすることで最適化されます
ソートに参加するレコードの数を減らします
必要な場合以外はデータをソートしないでください
リソースを消費する操作、SQLステートメントの使用を避けるDISTINCT、UNION、MINUS、INTERSECT、ORDER BY を使用すると、リソースを消費する並べ替え (SORT) 関数を実行するために SQL エンジンが起動されます。DISTINCT では 1 つの並べ替え操作が必要ですが、他の関数では少なくとも 2 つの並べ替え操作が必要です
。
以上がMysq に関するよくある誤解の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。