什麼指數（ES）需要添加此查詢正常工作？

該查詢在我的慢查詢日誌彈出：什麼指數（ES）需要添加此查詢正常工作？

SELECT 
    COUNT(*)     AS ordersCount, 
    SUM(ItemsPrice + COALESCE(extrasPrice, 0.0)) AS totalValue, 
    SUM(ItemsPrice)   AS totalValue, 
    SUM(std_delivery_charge) AS totalStdDeliveryCharge, 
    SUM(extra_delivery_charge) AS totalExtraDeliveryCharge, 
    this_.type    AS y5_, 
    this_.transmissionMethod AS y6_, 
    this_.extra_delivery  AS y7_ 
FROM orders this_ 
WHERE this_.deliveryDate BETWEEN '2010-01-01 00:00:00' AND '2010-09-01 00:00:00' 
    AND this_.status IN(1, 3, 2, 10, 4, 5, 11) 
    AND this_.senderShop_id = 10017 
GROUP BY this_.type, this_.transmissionMethod, this_.extra_delivery 
ORDER BY this_.deliveryDate DESC;

表是InnoDB和擁有大約880K行和9-12秒之間需要執行。我嘗試添加下列指數ALTER TABLE orders ADD INDEX _deliverydate_senderShopId_status (deliveryDate , senderShop_id , status, type, transmissionMethod, extra_delivery);，但沒有實際收益。任何幫助和/或建議是歡迎

這裏是查詢執行計劃現在：

 
id  select_type table type possible_keys key     key_len ref rows filtered Extra 
1  SIMPLE  this_ ref      FKC3DF62E57562BA6F 8   const 139894 100.00 Using where; Using temporary; Using filesort

我拿出possible_keys值出來的文字，因爲我認爲它在表中列出的所有索引。（FKC3DF62E57562BA6F）所使用的關鍵看起來像

 
Keyname    Type Unique Packed Field   Cardinality Collation Null Comment 
FKC3DF62E57562BA6F BTREE No  No  senderShop_id 4671  A

來源

2010-09-28 Tudor Constantin

deliveryDate的列類型是什麼？ – Thilo 2010-09-28 08:20:57

索引應與查詢計劃分析結合使用，以查看它們如何被真正使用。關於數據庫如何基於數據庫完成的優化使用索引並不總是很明顯。發佈您的查詢計劃與此索引，然後我們將在一個更好的位置來幫助 – InSane 2010-09-28 08:23:49

@Thilo - deliveryDate是datetime – 2010-09-28 08:33:27

我要告訴你一件事，你可以看看以提高速度。

您一般只在對未知或不適用的行中的數據NULL值。在我看來，因爲無論如何您都將NULL視爲0，您應該考慮擺脫它們並確保所有extrasPrice值爲0，因爲它們之前爲NULL，以便您可以擺脫時間處罰3210。

事實上，你可以走一步，並介紹另一列稱爲totalPrice您有插入/更新觸發器與實際值ItemsPrice + extrasPrice或（ItemsPrice + COALESCE(extrasPrice,0.0)如果你還需要的extrasPrice爲空）設置。

然後，您可以簡單地使用：

SELECT 
    COUNT(*)   AS ordersCount, 
    SUM(totalPrice) AS totalValue, 
    SUM(ItemsPrice) AS totalValue2, 
    :

（我不知道，你應該有兩個輸出列具有相同的名稱，或者是否是一個錯字，這將是，在最壞的情況中，錯誤，充其量，混淆）。

這將移動計算的成本，插入/更新時間，而不是選擇時間，在攤銷所有的選擇是成本 - 大多數數據庫表中讀取的次數遠遠多於寫的。數據的一致性由於觸發器而保持不變，並且性能應該更好，但需要考慮一些存儲要求。

但是，因爲絕大多數的數據庫的問題是「我怎樣才能獲得更快的速度？」而不是「如何使用更少的磁盤？」，這通常是一個好主意。

另一個建議是提供關於降低你的結果集最快（高基數）的列中的非複合索引。換句話說，如果您在表格中僅存儲了兩週的數據（14個不同的日期），但是有400個不同的商店，則您應該有一個senderShop_id索引，並確保您的統計數據是最新的。

這應該引起DBMS執行引擎，以削減使用該密鑰，以便後續操作更快的結果集。

上deliveryDate,senderShop_id,...的複合指數將無法使用senderShop_id來削減的結果，因爲關鍵的排序將是senderShop_id內deliveryDate。

來源

2010-09-28 08:36:09 paxdiablo

什麼指數（ES）需要添加此查詢正常工作？

回答

相關問題