Question

我有查询

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

只要执行任何类型的ORDER BY操作并使用函数/ math（+0）修改值，您就会强制MySQL对结果集中的每个字段进行转换，这就是为什么你得到temporary。

您可以发布表的结构，以便我们可以看到您拥有的索引和字段类型吗？

Answer 2

我们必须注意LEFT JOIN的查询。这种JOIN必须在右侧indexed表格中使用。你检查了indexes ??

如果它们没问题并且您的表格中有太多行，那么即使它尽可能地进行了最优化，也可能会导致查询的延迟。

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）。这应该从连接中取出，并应放在where：

中

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

如果前者不被任何东西逼迫。

我希望这会有所帮助。

我的sql查询优化简单查询

3 个答案: