5

file_category_tblファイルとカテゴリ間の関係を表す次の表 ( ) があります。

fileId - bigint(20)         
categoryId - bigint(20)
order - int(10)

カテゴリ内のファイルを注文できるように、注文フィールドがあります...したがって、私の質問は、次の最適なパフォーマンスのためにどのインデックスが必要かということです:

SELECT * FROM file_category_tbl WHERE categoryId="3" ORDER BY order ASC

fileIdUNIQUE ( , categoryId);という一意のインデックスがあります。fileId同じものはあり得ないからcategoryIdです。これが検索対象であるため、 のインデックスも取得しcategoryIdました。?...のインデックスも取得しましたが、orderこれは必要ですか? これだけをやっているorderByので...

レスポンダーによろしく... J

4

2 に答える 2

2

ORDER BY最適化で文書化されているように：

場合によっては、MySQLはインデックスを使用してを解決できませんORDER BYが、それでもインデックスを使用してWHERE句に一致する行を検索します。これらのケースには、次のものが含まれます。

[ deletia ]

  • ORDER BY行のフェッチに使用されるキーは、 ：で使用されるキーと同じではありません。

    SELECT * FROM t1 WHEREkey2 =定数ORDERBYkey1 ;

したがって、現在のインデックスをソート操作の実行に使用することはできません。ただし、同じページにも次のドキュメントがあります。

インデックスの未使用部分と余分な列がすべて句内の定数であるORDER BY限り、インデックスがインデックスと完全に一致していなくても、インデックスを使用できます。次のクエリは、インデックスを使用してパーツを解決します。ORDER BYWHEREORDER BY

[ deletia ] 

SELECT * FROM t1
  WHEREkey_part1 =定数
  ORDERBYkey_part2 ; _ _

したがって、複合インデックスオーバーは、フィルター操作と並べ替え操作の両方(categoryId,order)に使用できます。これは、このクエリの最適な結果です。

于 2012-09-02T19:11:41.983 に答える
1

私の理解によると、インデックス作成は賢明であり、クエリのパフォーマンスに役立ちます。Primary Keyただし、組み合わせたものだけではなく、テーブルにインデックスを作成することもお勧めしますUnique Index

私がこれを言っている理由は、このテーブルのレコードのいずれかを参照したい場合、それを削除したり、他の機能を実行したりする場合に、主キーが役立つからです。一方、すべてのフィールドが必要であり、主キー フィールドを使用して 4 つのフィールドを取り込む必要があるため、実際にはクエリのパフォーマンスが低下する可能性があります。その解決策として、結果に必要な列を指定できます。

これが理にかなっていることを願っています:-)

于 2012-09-02T19:08:05.417 に答える