前几天发现一个页面加载缓慢,大概得有个二三十秒的样子,一开始并没有当回事以为第一次打开加载缓慢,后来反复打开,每次都加载十分缓慢,于是我开始排查问题

页面上显示大概也就两万多条数据,而且还进行了分页,按理说不应该这么慢,于是我把执行的sql拿出来,单独执行了一下,这一试发现了问题严重性,单单这一个sql的执行时间就得有二十多秒, 这个sql是进行了inner join关联查询的,查看两张表一张有5000多条数据,另一张有两万多条数据,这样算起下来笛卡尔积一下子数量一试相当庞大的,如果要是进行了全表扫描那可不得炸了

于是首先受用explain命令来查看了一下sql,果然进行了全面扫描,经过返回的测试,最终将问题定格在了order by上面.此时还是一头雾水,于是百度查询果然出现问题的不止我一个,究其原因:

1.如果我们不使用order by字段排序，那么使用inner join后 只需要获取分页数据即可
2.但如果我们使用时间字段排序，这个时候我们需要对inner join的结果进行排序，而排序字段索引又没有生效(使用的是filesort)，所以就很慢了。
3.至于排序字段的索引为什么不生效，我们先看下 为什么MySQL会使用 filesort，官方解释如下：

Using filesort：
MySQL must do an extra pass to find out how to retrieve the rows in sorted order. The sort is done by going through all rows according to the join type and storing the sort key and pointer to the row for all rows that match the WHERE clause.
翻译过来通俗点讲就是:由于索引不满足你的sql，mysql需要对数据行进行一次额外的排序操作，这个排序操作既费空间又费时间。当数据量较少的时候并不会对应用产生多大影响，但数据量一多，就会出现非常可怕的后果，轻则服务响应变慢，重则拖垮服务，甚至引发雪崩效应导致应用宕机。

使用 order by后查询速度很慢的可能原因 使用 order by后查询速度很慢的可能原因

• 由于数据库两张表的字段编码不一致导致的。
• 由于Using filesort排序导致的。
• 由于没有走索引导致的。
• 使用组合索引排序时，使用的顺序不对，需要保证顺序。

最后说一下我的解决办法,将联表的相关外键都加上索引,查询速度一下就降到了1秒以内