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的主键索引。
