sql陳述句：
SELECT
o.order_id,
SUM(o.discountAmount) AS discountAmount,
s.store_name,
o.create_time AS create_time,
o.cashPay AS cashAmount,
o.cardPay AS cardAmount,
m. NAME AS realname,
o.sn,
SUM(o.order_amount) AS order_amount,
o.aliPay AS aliPay,
o.wechatPay AS wechatPay,
o.payeasePay AS payeasePay
FROM
es_daycount_order o
LEFT JOIN es_daycount_order_items i ON i.order_id = o.order_id
LEFT JOIN es_goods AS g ON i.goods_id = g.goods_id
LEFT JOIN es_member AS m ON o.operator_id = m.member_id
LEFT JOIN es_store AS s ON m.store_id = s.store_id
WHERE
o.store_id IS NOT NULL
AND o.store_id IN (190, 192)
AND o.create_time > 1483200000
AND o.create_time < 1513958399
AND (
o.pay_status = 2
OR o.pay_status = 3
)
AND o.sn NOT LIKE '%SO10%'
AND o.sn NOT LIKE '%SO20%'
GROUP BY
i.order_id
ORDER BY
create_time DESC;
explain結果
現在查詢時間是8秒左右。請問怎么優化
uj5u.com熱心網友回復：
1、考慮表的資料量2、考慮表的欄位的多少
3、多表關聯，準備欄位索引
uj5u.com熱心網友回復：
我又來瞎說了，你這種陳述句要看什么場景了:1. 如果是高并發，高訪問量的互聯網應用，寫這樣的SQL，就該好好檢討一下了，
2. 如果是報表的話，8秒的時間，是能夠接受的，
說了這么多，我給點建議吧:
1. 如果是互聯網應用，
第一：通過執行計劃，算好區分度來添加合適的索引。
第二： 把應用服務化吧，給到資料庫中的都是一些簡單的查詢，(這也算是業務上的SQL優化了)
2. 如果是報表的話，可以放入大資料中計算，如果沒有大資料組呢，也沒關系，至少放在叢庫(報表庫)吧，別把主庫壓垮了，
思考: 想想還有多少這樣的SQL，也像上面的步驟解決下吧。
最后: 個人微信公眾號《andyqian》 更新了不少MySQL相關的文章，希望對你有所幫助！
uj5u.com熱心網友回復：
感謝，這個確實是報表的
uj5u.com熱心網友回復：
嗯~~~，是考慮了，但是考慮不出來
uj5u.com熱心網友回復：
這個還是如樓上那位所講，根據你的實際業務場景去考慮。對這種更新頻率高，資料量大的表，在開始建表的時候就該考慮是否拆分，當然現在也可以拆分。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/99582.html
標籤：MySQL
上一篇：關于mysql的logfile