2016-08-24 11 views
1

1つのテーブルに複数のcssインポートをマージしましたが、この呼び出しには約70秒かかります。それをスピードアップするためにこれを書き換える方法はありますか?SQL - 高速化パフォーマンス

SELECT 
    `table_merged`.Property AS 'Property', 
    AVG(`table_merged`.`Value`) AS 'Average Asking Price' 
FROM 
    `table_merged` 
WHERE 
    `table_merged`.`Area` LIKE '%NW1%' 
    AND `table_merged`.`Property` LIKE '%2-bed flat%' 
    AND `table_merged`.`Year` = '2016' 
GROUP BY 
    `table_merged`.Property, `table_merged`.`Year` 
ORDER BY 
    `table_merged`.Property ASC 

出力がそのままクエリを行うことができます多くはありません

| Property | Average Asking Price 
| 2-bed flat | 751427.1935581862 
+0

あなたは '%..%' "like"とマッチしています。フルテーブルスキャンを強制するため、本質的に遅いです。 –

+0

'LIKE'は本当に物事を混乱させる。フルテキストインデックスを使用する必要があるかもしれませんが、それは検索している文字列では難しいかもしれません。 –

+0

2ベッドフラットでLIKEを削除しましたが、パフォーマンスの改善は見られませんでした - NW1の@GordonLinoffフルテキストインデックス –

答えて

0

です。今最大のパフォーマンスを達成するには、%...%のスタイルLIKEステートメントを使用してください。コメントでGordonがすでに言及しているように、これは基本的にMySQLがインデックスを使用する能力を取り除きます。

ここでの最適な解決策は、スキーマを少し変更することです。私はプロパティのタイプ(2ベッドフラットのような)といくつかの種類のコード(ちょうどintである可能性があります)を格納するテーブルを作成することをお勧めします。 LIKEステートメントを使わないでコードを検索すると、索引を使用できるようになります。同様の文字列を絶対に検索する必要がある場合は、はるかに小さな表の副選択として行うことができます。さらに明確にするため

編集:

あなたは%2-bed flat%に一致するテキストの任意の文字列を探しています。私の前提は、cute 2-bed flat2-bed flat near the water、または他のランダムなマーケティングのような文字列があるため、これをやっているということです。あなたのLIKEステートメントを最適化する方法はありません。彼らは遅く、それは人生の不幸な事実です。

現在のテーブルに列を追加します。文字列が文字列%2-bed flat%と一致する場合は、2bfのような値を与えます。あなたがそれをしている間、あなたが使うかもしれない他の検索文字列でこれを行うことができます。この列にインデックスを挿入します。

これが完了したら、集中的なLIKEステートメントを使用する代わりに、新しい列に対して索引検索を行うことができます。

+0

- 別のテーブルに戻ってジョインセットを試してみたらどうでしょうか? –

+0

最初のテーブルは年度バッチですが、2013年と2016年の平均価格を求めるクエリを実行する必要があります –

+0

問題は結合ではなく、問題はどのように検索しているかです。このような 'LIKE'文のスタイルは本質的に遅いです。 – Jacobm001