Mysq に関するよくある誤解

PHP中文网
リリース: 2017-06-20 15:37:02
オリジナル
1265 人が閲覧しました

よくある誤解

    1. count(1) と count(primary_key) は count(*) よりも優れています

    多くの人は、数を数えるために count の代わりに count(1) と count(primary_key) を使用します(*) の方がパフォーマンスが良いと考えられていますが、実際にはこれは誤解です。一部のシナリオでは、データベースが count(*) カウント操作に対して特別な最適化を行っているため、パフォーマンスが低下する可能性があります。
      1. count(column)とcount(*)は同じです

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

                • ソートに参加するレコードの数を減らします

                • 必要な場合以外はデータをソートしないでください

                • リソースを消費する操作、SQLステートメントの使用を避けるDISTINCT、UNION、MINUS、INTERSECT、ORDER BY を使用すると、リソースを消費する並べ替え (SORT) 関数を実行するために SQL エンジンが起動されます。DISTINCT では 1 つの並べ替え操作が必要ですが、他の関数では少なくとも 2 つの並べ替え操作が必要です

                以上がMysq に関するよくある誤解の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

                関連ラベル:
                ソース:php.cn
                このウェブサイトの声明
                この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
                人気のチュートリアル
                詳細>
                最新のダウンロード
                詳細>
                ウェブエフェクト
                公式サイト
                サイト素材
                フロントエンドテンプレート