在Order By中使用MATH可以提高性能嗎？

我有一個問題只有：假設我們有一個表（activity_feed）與1.000.000行，表格（activity_feed_per_user）與誰請求供稿用戶和活動之間的關係，他會看到和表白衣一些統計從所有被應用程序拖垮的活動。在Order By中使用MATH可以提高性能嗎？

，如果我有一個軍銜命令的結果（即甚至時間取決於，因此是可變的每一秒），這是查詢很好用？或者根本不是？

EXPLAIN EXTENDED SELECT feed.activity_id, feed.body, counter.comments, counter.likes, user.username, 
(0.25 * (
     (1/TIMESTAMPDIFF(MINUTE,feed.datetime,now())) + 
     (1 - (1/(((comments + 1)* 1) + ((likes + 1) * 0.5)))) + 
     activity_type.peso + 
     user_affinity.affinity 
    )) as ranking 
FROM activity_feed_per_user as feed_user 
INNER JOIN activity_feed as feed ON feed_user.activity_id = feed.activity_id 
INNER JOIN activity_type ON feed.activity_type = activity_type.activity_type_id 
INNER JOIN activity_social_counter as counter ON feed_user.activity_id = counter.activity_id 
INNER JOIN user_info as user ON user.user_id = feed.user_id 
INNER JOIN user_affinity ON feed.user_id = user_affinity.user_related AND user_affinity.user_id = '1' 
WHERE feed_user.user_id = '1' 
ORDER BY ranking DESC

這是上有沒有索引具有看看每一行的查詢產生，所以你提出我能爲返回巨大結果集的查詢會降低性能的值解釋

1 | SIMPLE | user_affinity | ref | PRIMARY | PRIMARY | 4 | const | 2 | 100.00 | Using temporary; Using filesor 
1 | SIMPLE | user | eq_ref | PRIMARY | PRIMARY | 4 |db.user_affinity.user_related | 1 | 100.00 
1 | SIMPLE | feed_user | ref | PRIMARY | PRIMARY | 4 | const | 9 | 100.00 | Using index 
1 | SIMPLE | feed | eq_refvPRIMARY,activity_type,user_idvPRIMARY | 4 | db.feed_user.activity_id | 1 | 100.00 | Using where 
1 | SIMPLE | activity_type | eq_ref | PRIMARY | PRIMARY | 1 | db.feed.activity_type | 1 | 100.00 
1 | SIMPLE | counter | eq_ref | PRIMARY | PRIMARY | 4 | db.feed_user.activity_id | 1 | 100.00

來源

2013-03-29 Monte

在您的查詢將強制「使用文件排序」操作的ORDER BY，而且可以在大型結果集是昂貴的操作。（MySQL有時可以使用索引來滿足ORDER BY，避免使用「使用filesort」操作;但在您的情況下，將需要爲結果集中的所有行評估表達式（「數學」）

如果它是返回你所需要的結果集，然後將查詢看起來不錯。

來源

2013-03-29 12:55:31 spencer7593

另一個問題是（我認爲）的應用程序請求有限的結果（ES LIMIT 0,10 - 然後 - LIMIT 11，20），這，也許會迫使查詢，使這個昂貴的工作有很多的時間（每用戶） – Monte

@Monte：非常好的一點。爲了僅「獲得」前10行，查詢將不得不執行排序操作。後續的查詢只需要「接下來的10行」就必須再次執行排序操作。如果這個查詢將頻繁運行，那麼實現緩存層可能是合適的。 – spencer7593

緩存這種類型的查詢的問題是，對於2/4，排名，每秒更改（以及每個用戶）。天哪！ – Monte

ORDER BY 。

來源

2013-03-29 12:47:56 Joni

我知道，但我看不到更好的解決方案。我能做的唯一一件事就是刪除排名和排序ID DESC造成的。但是，這不是一個解決方案... – Monte

如果您需要的結果排序是需要時間對它進行排序，無論你在數據庫中或在代碼中做到這一點。有沒有辦法解決它。 – Joni

這是真的。以這種方式甚至很難緩存結果，與memcache。在這一點上，唯一要做的事情是測試這個查詢，如果它不工作去od，刪除排名和訂單的id。 – Monte

在Order By中使用MATH可以提高性能嗎？

回答

相關問題