1. ct_monitor 表記錄200多萬條記錄
2. device 表 45 條記錄
3. 兩個表進行join並排序 需要 16.750 秒
我們一看，就知道這個結果 明顯的 不符合常識！！！
如果我們 先查 ct_monitor 表的 主鍵 排序之后的 6條記錄，然后用那6條記錄來關聯 device表，根本不可能需要16秒的時間！！！！
4. 如果去掉 order by mm.id desc 時，只需要 0.001 秒：
可以看到問題主要是 order by mm.id desc 導致了使用磁盤進行文件排序。而又因為 ct_monitor表記錄有200多萬，所以需要耗時很長。
5. 如果 把 inner join 改成 left join :
又只需要0.001秒了。
可以看到這里 ct_monitor 作為了驅動表，只有 ct_monitor 表的主鍵 排序查詢到了 6條記錄，然后 在根據 ct_monitor.deviceId 來關聯 device的主鍵。
到這里，我們可以想到可以使用 force index 來強制 ct_monitor 表走 主鍵索引：
這樣，我們強制 ct_monitor 表使用主鍵索引，先使用主鍵排序獲取到6條記錄之后，在用 ct_monitor.deviceId 去關聯 device表的主鍵，這個結果才是符合我們想象的一個執行過程。
而不是：
而不是：使用 ct_monitor 表的 deviceId 來關聯 device 的 id，然后對整個結果進行 排序，在取6條記錄。因為這樣無法使用 ct_monitor 的主鍵進行排序。
最后的優化方案是使用 force index (primary) 來強制使用 ct_monitor的主鍵索引。