OR検索使用時の設計について

レストラン、不動産、求人などの検索サイトは多数のチェックボックス検索項目があり、
「OR検索」が多発するため、索引がうまく使用されず、件数が増えるとすぐに遅くなると
思います。

設計上の配慮はどのようなことがあるのでしょうか。

index_merge である程度、効果があるのでしょうか。
http://dev.mysql.com/doc/refman/5.1/ja/index-mer …

No.2 回答者： Siegrune 回答日時： 2014/01/19 22:29

>「OR検索」が多発するため、索引がうまく使用されず、件数が増えると

>すぐに遅くなると思います。
多分その通りと思います。
特に、指定無し（あるいはすべて指定）があるために頭が痛いことになります。
⇒指定なしの場合もいちいち検索条件に指定するのか、しないのか。
また、名称などのあいまい検索が含まれることも考慮しておいたほうがいいと思います。
例えば店名のあいまい検索など。

>index_merge である程度、効果があるのでしょうか。
条件が多すぎると、期待薄としか思えませんが。

対策としては、
条件検索用テーブル（インデックス付き）と
情報格納用テーブル（プライマリキーのみ）を分けるというのも
ひとつの方法かと思います。

例）レストラン

レストラン情報テーブル　
レストランＩＤ、レストラン名、ジャンル（和洋中・・・）、地域・・・・

レストラン名検索テーブル
レストラン名、レストランＩＤ

ジャンル検索テーブル
ジャンル、料理種別、レストランＩＤ

地域検索テーブル
地域（必要に応じて複数階層）、レストランＩＤ

・・・

検索画面
店名：（指定無し）
料理長名：（指定無し）
ジャンル：北京料理、上海料理にチェック
料理種別(ジャンルに従属)：ラーメン以外の全部にチェック
都道府県：東京都を選択
市区町村：千代田区、江戸川区にチェック
地域：すべてを選択
営業時間区分：（指定無し）
朝昼夜区分：（指定無し）
客単価：千円未満、二千円未満、三千円未満を選択
・・・


検索方法（条件が指定されたところだけinner joinで条件検索用テーブルを追加。）
select * from レストラン情報テーブル tx
inner join ジャンル検索テーブル t2
on tx.レストランID = t1.レストランID
and t2.ジャンル in (北京料理,上海料理)
and t2.料理種別 in (・・・)
inner join 住所検索テーブル t3
on t3.都道府県 in (東京)
and t3.市区町村 in (千代田区,江戸川区)
・・・・

/* inの中の漢字でかいたところは、おのおのに相当するコード */
といった感じ。

No.1 回答者： yambejp 回答日時： 2014/01/14 15:18

カラムを分ける場合と、テーブルをわける場合が想定されます

前者はスケーラビリティが悪いですがinで絞り込みをすると書式が簡便で処理も速いと思います
後者は別テーブルでマッチさせた条件でjoinするので多少複雑ですが、拡張しやすいです。
どちらでもインデックスは問題なく利くとおもいますよ