簡單的查詢

Question

我的SQL查詢優化我查詢

SELECT r.*,u.name AS name, u.username AS username 
FROM jos_js_res_record AS r 
LEFT JOIN jos_users AS u on u.id = r.user_id 
LEFT JOIN jos_js_res_record_values AS f on f.record_id = r.id AND f.field_type = 'digits' 
AND f.field_label = 'Price' 
WHERE r.section_id = 2 
AND MATCH (fieldsdata) AGAINST ('article' IN NATURAL LANGUAGE MODE) 
AND r.title like 'A%' 
ORDER BY f.field_value + 0 desc, f.field_value desc 

我不知道爲什麼，但它產生解釋「利用地方;使用臨時;使用filesort。我盡我所知來優化這個查詢，但沒有結果。據我所知這是因爲加入了jos_js_res_record_values和ORDER BY。如果我評論ORDER BY或將其更改爲ORDER BY r.created使用臨時消失。

Answer 1

我們必須注意與LEFT JOIN查詢。這種JOIN必須使用右表indexed。你檢查了你的indexes ??

如果它們沒問題，並且表格中的行數過多，那麼即使它儘可能最優化，它也可能會導致您查詢的問題。

Answer 2

只要您執行任何類型的ORDER BY操作並使用函數/數學（+0）修改值，您將強制MySQL對結果集中的每個字段進行轉換，你得到temporary。

你可以發佈你的表的結構，以便我們可以看到你有什麼索引和字段類型？

Answer 3

1）爲以下字段創建索引： jos_users.id jos_js_res_record_values.record_id jos_js_res_record_values.field_type jos_js_res_record_values.field_label jos_js_res_record.section_id fieldsdata jos_js_res_record.title

2.） 這應該從連接中取出並放在其中：

f.field_type = 'digits' 
AND f.field_label = 'Price' 

3.）其中A和B： 如果A不太可能（在表中很少見），並且它的計算速度比B快，那麼這是一個好的順序。否則，當B和A比，其中A和B 同樣是真實的或更快，但最好是對左側的操作數更概率，因爲這些公式的：

False and B = False 
True or B = True 

在上述公式適用的情況B完全沒有計算，你贏得了很多時間。所以，如果你耐心地用更多的價值類型來測試你的操作數，你可以得到理想的訂單。

4）取而代之的是：

ORDER BY f.field_value + 0 desc, f.field_value desc 

你需要這個：

ORDER BY f.field_value desc, f.field_value desc 

如果前者不受任何強迫。

我希望這會有所幫助。