2

次のスキーマを持つMySqlテーブルを考えてみましょう

+-------------------+------------+------+-----+-
| Field             | Type       | Null | Key | 
+-------------------+------------+------+-----+-
| id                | int(11)    | NO   | PRI | 
| user_id           | int(11)    | YES  | MUL | 
| following_user_id | int(11)    | NO   | MUL | 
+-------------------+------------+------+-----+-

今、私は次のようなクエリが必要です

select * from table where user_id = <x> and following_user_id = <y>;

そしてまた

select * from table where following_user_id = <x> and user_id = <y>;

したがって、次のように2列の複合インデックスを検討しています。

index(user_id, following_user_id)

と

index(following_user_id, user_id)

1) インデックスは必要に応じて作成されますが、レコードが多数 (~ 数百万) の場合に機能しますか?

2) 適切なタイミングで適切なインデックスを使用すると、インデックスによってクエリが高速化されますか?

PS: クエリは必要ありませんsort/range selection。直接一致クエリのみが必要です。この要件に利用できるより良いインデックス作成スキームはありますか?

4

1 に答える 1

2

クエリは、コンパイラの観点からは同じです。どちらのインデックスも機能します。ステートメント内の句の順序はwhere、インデックスのクエリを修飾する上で重要ではありません。

ただし、不等式または句が 1 つしかない場合は、インデックス内の順序によって違いが生じます。

したがって、インデックスindex(user_id, following_user_id)は次のような状況で役立ちます。

  • user_id を直接比較する (<> を除く)
  • user_id = XXX および folowing_user_id = YYY
  • user_id = XXX および folowing_user_id /IN の値

次の場合には使用されません。

  • 次のユーザー ID < YYY
于 2013-02-21T18:59:27.983 に答える