mysql の最適化 (5) インデックス作成とソート

並べ替えでは 2 つの状況が発生する可能性があります:

1: インデックスをカバーする場合、インデックスに対して直接クエリを実行する場合、順序があり、
インデックスを使用するか、クエリ時にインデックス フィールドに沿ってクエリを並べ替える可能性があります。 現時点では、ソートコストは低いです

2: まず、データを取り出し、ファイルソート用の一時テーブルを作成します(ファイルソートですが、ファイルはディスク上またはメモリ内にある可能性があります)



私たちの目標 - ---- 取り出します データ自体が順序付けされています!
並べ替えにはインデックスを使用します。



例: 商品製品テーブル、(cat_id, shop_price) が結合インデックスを形成します。

where cat_id=N order by shop_price 、インデックスを使用して並べ替えることができます。

select Goods_id,cat_id,shop_price from Goods order by shop_price;

// where を使用すると、shop_price インデックスに従って取り出した結果自体が順序付けされます。



select Goods_id, click_count による商品注文の cat_id,shop_price;

// filesort を使用すると、ファイルのソートが使用されます。つまり、取得された結果が再度ソートされます

mysim は実行中にそれらをすべて見つけてソートし、次に戻って行を取得します。インデックスが存在する限り、インデックスのクリック数と ID を組み合わせてインデックスを構築するのは実際にはそれほど大きなことではありません

innodb 葉のすぐ下

重複したインデックスは意味がありません

2 つのインデックスを冗長化することで効率が向上します。

インデックスの断片化とメンテナンス

大規模な Web サイトでは、基本的にディスク上のデータは削除されず、再利用が難しい短いバイトは容易には再利用されません。

脆弱性を修正します

長期間のデータ変更プロセス中に、インデックスファイルとデータファイルの両方に穴が生成され、フラグメントが形成されます。

nop操作(実質的な影響を与えない操作)を通じてテーブルを変更できます。

例: テーブルのエンジンは innodb であり、
テーブル xxx エンジン innodb を変更してデータを実質的に変更できます。テーブルの変更には影響しませんが、データは再編成されます



。 table テーブル名を修復することもできます。



注: テーブルのデータとインデックスの断片を修復すると、すべてのデータ ファイルが再配置されて整列します。テーブル内の行数が比較的多い場合、非常にリソースを消費する操作でもあるため、頻繁に修復することはできません。サイクルは長くなります。 ！ ！ ！



テーブルの更新操作が頻繁であれば、週次・月次での修復も可能です

頻度が低い場合は、より長い期間での修復も可能です

以上が内容です。 mysql の最適化 (5) インデックス作成とソート 、その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。