これは問題ではありませんが、サイトの最適化に属します。私はホテルの11万件の記録を持っています。SELECT何かクエリを使用すると、110kレコードからデータが抽出されます。
3つ星以上の評価のホテルリストを検索した場合、価格は100〜300ドルで、メキシコシティ内にあります。45の一致する結果が得られたとします。
さらに改良を加えると、45の一致のみからデータが抽出され、110Kのデータには対応しない他の方法はありますか？
4 に答える
1
キーは私の友人のインデックスです... WHERE で使用されるすべてのアイテムのインデックスがあることを確認してください。これにより、選択時のカーディナリティが減少します...
110k 行はまだ MySQL の非常に小さなデータ セットであるため、テーブルに正しいインデックスを作成していなくても、パフォーマンスの問題はあまり発生しません。
于 2012-06-19T11:45:35.870 に答える
0
データの更新頻度によって異なります。
見る。
私が言っているのは、さらに改良を加えたときに他の方法があるということです。それは、45 の一致のみからデータを引き出し、110K のデータには対応しません。
次に、それらの 45 行を表示し、それにクエリを適用します。
于 2012-06-19T11:45:11.660 に答える
0
クエリを使用してビューを作成する
Create view refined as select * from ....
その後、そのビューにさらに選択クエリを追加します
Select * from refined where ...
于 2012-06-19T11:45:28.730 に答える
0
まず第一に、私はブライアンに同意する傾向があり、インデックスは重要です。
最も頻繁に使用されるクエリの種類を確認し、それに応じてテーブルに複数列のインデックスを作成します。インデックス内の列の順序は重要であることに注意してください (インデックスはツリーであるため、最初の列はツリー ルートに表示されるため、クエリがその列を使用しない場合、ツリー全体は役に立ちません)。
スロー クエリ ログを有効にして、実際に時間がかかるクエリ (ある場合) を確認したり、インデックスを使用していないクエリを確認したりして、時間の経過とともにインデックスを改善できるようにします。
そうは言っても、テーブル データのほとんどが read である場合、クエリ キャッシュは実際のパフォーマンスを向上させます。これは、mysql クエリ キャッシュに関する有用な記事です。
于 2012-06-19T11:53:44.180 に答える