今天寫出一個十分弱智的bug！

• 2020 年 3 月 5 日
• 筆記

今天寫出一個十分弱智的bug，記錄一下，提醒自己以後別這種犯錯，不怕丟人哈~

在寫一個分頁查詢記錄的sql時，要根據添加的時間逆序分頁輸出，之前的寫法是醬紫：

select      record.a,      y.c  from      (          select              a,b          from              x          order by timestamp desc          limit 0,10      ) record  left join y  on record.b = y.d;

因為一些新的需求，要在後面加一些where條件，limit操作不能在嵌套查詢裡面加了，於是乎把limit 0,10提出來放到最外面，結果order by還留在裡面。

我當時想嵌套查詢出來的record表已經按timestamp欄位逆序排列了，再left另一張表，最終再limit出來的結果應該也是逆序的，但結果卻很打臉，是正序的。

首先控制變數，程式碼回滾到之前，把後來加的各種邏輯都去掉，還原到上述sql，只把limit 0,10移到最後，發現timestamp是正序的，那麼問題應該就出在這裡了，與後來加的其他邏輯沒有關係。

那麼再試一下刪掉limit操作，結果timestamp是無序的！

這不可能啊，於是認真看了下數據，發現一些規律，可能是按y表的自增id或created_at時間欄位排序的（因為這兩個欄位是索引欄位），那麼到這裡，我們至少可以得到一個簡單的結論，就是聯表查詢結果，不是按照嵌套查詢中的order by排序的，現在正向一看，確實不可能按這個排序，因為括弧裡面的邏輯對括弧外是不可見的。

還有個問題，上述去掉limit後，最終不是按left join主表的順序輸出，按照我們常理想像，mysql是循環主表的記錄去關聯另一張表，那麼輸出的順序應該還是主表的順序啊，但結果卻是按另一張表的欄位排序的，這又是為什麼呢？圖解 5 種 Join 連接這篇推薦大家看下。

去官方手冊中找找線索，發現order by模組中有這麼一句話。

再去limit模組中看一下

從以上兩個截圖中，我們可以發現一些端倪，limit操作會對查詢有一些優化，查詢到指定條數的數據，就可以提前結束了，比如我們本文中的left操作，拿到10條結果就結束查詢執行緒，返回客戶端。

我猜測，如果沒有limit操作，反正全部都要join，可能mysql會對循環邏輯做一些優化，不一定要按主表來循環，思想類似於java編譯中的重排序，也對應了上面截圖中的那句話。

採用最簡單、最粗暴的方式，直接把order by 和 limit操作放到最外面就ok啦，其實效率上並沒有什麼降低，只要索引建的合理即可。

作者：春卷要炸著吃

www.cnblogs.com/supercj/p/10333918.html

END