請教SQL執行效率問題-有解無憂

SQL 1: 執行時間 0.826秒
SELECT
  tenant_id,
  o2o_user_id
FROM
  crm_point_sync_i2o
WHERE sync_status = 0
  AND next_execute_time < NOW()
  AND tenant_id IN
  (SELECT
    tenant_id
  FROM
    crm_config
  WHERE is_enable = 1
    AND is_sync = 1)
ORDER BY try_times ASC,
  update_time DESC
LIMIT 1000;

SQL2 ，在sql1的基礎上把排序去掉了，按理說，應該更快啊，怎么慢這么多: 執行時間2.212 秒
SELECT
  tenant_id,
  o2o_user_id
FROM
  crm_point_sync_i2o
WHERE sync_status = 0
  AND next_execute_time < NOW()
  AND tenant_id IN
  (SELECT
    tenant_id
  FROM
    crm_config
  WHERE is_enable = 1
    AND is_sync = 1)
    LIMIT 1000

執行計劃如下：

uj5u.com熱心網友回復：

有 LIMIT 1000;
這個改變了取資料的順序，所以不加 ORDER BY 不一定快

uj5u.com熱心網友回復：

參考 1 樓 zjcxc 的回復:

有 LIMIT 1000;
這個改變了取資料的順序，所以不加 ORDER BY 不一定快

不加order by不一定快，那么為啥加了比不加要快很多

uj5u.com熱心網友回復：

參考 2 樓 xlycom 的回復:

Quote: 參考 1 樓 zjcxc 的回復:

有 LIMIT 1000;
這個改變了取資料的順序，所以不加 ORDER BY 不一定快

不加order by不一定快，那么為啥加了比不加要快很多

而且執行計劃差別那么大

uj5u.com熱心網友回復：

參考 3 樓 xlycom 的回復:

Quote: 參考 2 樓 xlycom 的回復:

Quote: 參考 1 樓 zjcxc 的回復:

有 LIMIT 1000;
這個改變了取資料的順序，所以不加 ORDER BY 不一定快

不加order by不一定快，那么為啥加了比不加要快很多

而且執行計劃差別那么大

另外，我現在把limit去掉，效果也是一樣，加了order by快很多

uj5u.com熱心網友回復：

不知道發什么神經，看不到圖
說說理論吧
有 ORDER BY 或 LIMIT 都可能導致執行計劃差異，所以效率有差異是正常的，關鍵是看那種情況的執行計劃更符合效率要求
畢竟執行計劃是根據陳述句和表結構、統計資訊評估出來的一種應該最佳的執行方式，但它只是應該，不是絕對
以雖然不加 ORDER BY 應該會快一些，但這并不絕對

uj5u.com熱心網友回復：

參考 5 樓 zjcxc 的回復:

不知道發什么神經，看不到圖
說說理論吧
有 ORDER BY 或 LIMIT 都可能導致執行計劃差異，所以效率有差異是正常的，關鍵是看那種情況的執行計劃更符合效率要求
畢竟執行計劃是根據陳述句和表結構、統計資訊評估出來的一種應該最佳的執行方式，但它只是應該，不是絕對
以雖然不加 ORDER BY 應該會快一些，但這并不絕對

你QQ多少，我加你，QQ討論下

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/101026.html

標籤：MySQL

上一篇：[跪求解決]百度服務器BCC下用yum安裝的mysql5.7.20無操作運行數小時自動shutdown

下一篇：vertica 資料庫掛掉問題error SP_receive: Connection closed by spread