SQL - 加速性能

我已經將幾個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

來源

2016-08-24 The Old County

你正在做'％..％'「like」比賽。由於它們強制進行全表掃描，所以它們本質上很慢。 –

'LIKE's真的搞砸了。您可能需要使用全文索引，儘管這對您正在搜索的字符串可能會非常棘手。 –

我已經刪除了2牀平板上的LIKE - 但我沒有看到性能改進 - @GordonLinoff NW1上的全文索引？ –

沒有可與查詢來完成，因爲它是很多。您現在最大的表現是您使用%...%款式LIKE報表。正如Gordon在評論中已經提到的那樣，這基本上消除了MySQL使用索引的能力。

這裏最好的解決方案是略微改變你的模式。我會建議創建一個表來存儲屬性的類型（如2牀平），然後某種代碼（可以只是一個int）。在沒有使用LIKE語句的代碼上搜索將使您能夠使用索引，並且如果您絕對必須搜索類似的字符串，則可以將它作爲更小表上的子查詢。

編輯爲進一步澄清：

您正在搜索文本的任何字符串匹配%2-bed flat%。我的假設是，你這樣做是因爲你有像cute 2-bed flat，2-bed flat near the water或其他隨機營銷的東西。沒有辦法優化您的LIKE聲明。他們很慢，這是一個不幸的事實。

我會爲您的當前表格添加一列。如果字符串匹配字符串%2-bed flat%，則給它一個類似於2bf之類的值。當你處理它時，你可以使用任何其他可能使用的搜索字符串來做到這一點。把一個索引放在這個列上。

一旦完成，而不是使用密集的LIKE語句，您可以只對新列進行索引搜索。

來源

2016-08-24 17:15:46 Jacobm001

- 如果我回到單獨的表格並嘗試做一組聯接，該怎麼辦？ –

最初的表格是分批批量生成的 - 但我需要運行一個查詢，詢問2013年和2016年的平均要價 –

問題不在於加入，問題在於您如何搜索它。這種'LIKE'聲明的風格本質上很慢。 – Jacobm001

SQL - 加速性能

回答

相關問題