记录一次sql慢查询优化经历

需求背景是直播列表页查询，查询、排序、分页，说一下排序逻辑吧，直播状态分为三种：直播预约，直播中，直播结束，后台可以置顶某场直播。首先按置顶排序，然后状态依次是直播中，直播预约，直播结束，如果两场直播都是非结束状态，按照预约时间倒序，如果两场直播都是结束状态，按观众数升序。

因为排序比较复杂，直接写sql不好写，所以把排序逻辑放在代码中实现，但是每次都需要取扫描全表，然后排序，再分页，因为考虑直播数据是实时变化的，所以代码中没添加缓存。除此之外，是否置顶，直播状态基数都很低，加索引不太合适，就没考虑加索引，每次查询都是走db，前期数据少还不明显，随着直播场次的增加，sql越来越慢，然后超过0.1s，开始出现慢查询，但是其实数据量也就是一千四左右，这时开始调整，最后和产品沟通结果只展示最近5天的直播量，同时对已经结束的直播做缓存处理，未结束的直接走db查询，保证相对准确，然后此时算是告一段落。

直到最近，做了一次压测，发现慢查询又出现了，只有查询列表页直播数量的sql，因为列表页查询会有两条sql，一条查总数，一条查数据，但是查询总数的sql当时是没有对直播状态做区分处理的，而查询数据的接口是区分的，所以在想可能这里也要根据状态做区分处理，直播结束的放在缓存中，未结束的查库。

目前考虑的解决方案：1、查数量sql也按状态区分 2、在预约时间上添加索引，因为之前是全表扫描，添加索引后type是range，这样可能对效率也会有提高。
未加索引：

添加索引：

具体结果有待考证，今天周末，明天上班和同事沟通一下，具体解决方案。