データベースのインデックス作成(2)_PHPチュートリアル

次に、もう少し複雑に ORDER BY 句がある場合はどうなるでしょうか。信じられないかもしれませんが、ほとんどのデータベースは、order by を使用するときにインデックスを作成することで恩恵を受けます。
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
少し混乱していますか？非常に簡単で、where 句でフィールドのインデックスを作成するのと同じように、ORDER BY 句でもフィールドのインデックスを作成します。
CREATE INDEX mytable_categoryid_userid_adddate
ON mytable (category_id,user_id,adddate);
注: " mytable_categoryid_userid_adddate" は "mytable_categoryid_userid_addda" に切り詰められます。 CREATE :
Sort (cost=2.03..2.03 rows=1 width=16)
-> mytable_categoryid_userid_addda を使用してインデックススキャン
mytable (cost=0.00..2.02 rows=1 width=) 16)
EXPLAIN
EXPLAIN の出力を見てください。少し怖いようです。もっとデータベース作業を行ってください。これで、パフォーマンスがどのように損なわれるかがわかりました。データベース自体の操作 そこで、データベースにさらにヒントを与えてみましょう。
並べ替えの手順をスキップするために、データベースに追加のヒントを与えます。ORDER BY ステートメントの where ステートメントにフィールドを追加します。これは単なる技術的なプロセスであり、他の 2 つのフィールドでは実際には並べ替え操作が行われないため、必要ありませんが、追加すると、postgres が何をすべきかを認識します。
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY category_id DESC,user_id DESC,adddate DESC;
通知: QUERY PLAN:
mytable の mytable_categoryid_userid_addda を使用して逆方向にインデックス スキャン
(コスト=0.00..2.02 rows=1 width=16)
EXPLAIN
は、私たちが期待していたインデックスを使用するようになり、インデックスの後ろから読み取りを開始できることを知っているので、ソートを回避できるほど賢明です。
上記は少し詳細ですが、データベースが非常に巨大で、毎日のページリクエストが数百万件に達する場合、大きなメリットがあると思います。ただし、複数のテーブルを組み合わせてクエリを実行するなど、より複雑なクエリを実行する場合、特に where 制限句のフィールドが複数のテーブルから取得されている場合はどうすればよいでしょうか?データベースは各テーブルのすべてを結合してから不適切な行を除外する必要があり、非常にコストがかかる可能性があるため、私は通常このアプローチを避けるようにしています。




http://www.bkjia.com/PHPjc/631059.html

www.bkjia.com