用户反馈系统慢，但是没描述具体是哪里慢，登录到其mysql数据库中，通过slow.log分析查看，其中有个sql出现的频率较多，而且耗时较长，先拿这个sql分析一下：
SELECT s.userid,s.status,MAX(s.lastaccess) AS lastaccess FROM sessions s WHERE s.status=0 GROUP BY s.userid,s.status;
初步看到的信息：返回22条数据，但是Rows_examined几乎是整张表的条数，这里心里就有个眉目了。
如何优化呢，我们大概有个套路：
1. 采用explain对语句进行分析
explain SELECT s.userid,s.status,MAX(s.lastaccess) AS lastaccess FROM sessions s WHERE s.status=0 GROUP BY s.userid,s.status;
我们看到，key走的是sessions_1的索引，其实这里我们可以看出端倪，但是为了把sql优化的方法讲出来，咱们继续。
查看表的索引
查看表的状态
Avg_row_length不大（对于返回数据时，这个值可以供参考分析）
查看表的栏位
（没啥大的字段，与上面联合查询分析）
2. 使用profile分析sql在哪里消耗的时间长
（很好的一个工具，可惜5.7以后profile信息将逐渐被废弃，mysql推荐使用performance schema）
set profiling=on;（或者=1）
几乎所有的时间都消耗在Sending data上。
这里“Sending data”并不是单纯的发送数据，而是包括“收集 + 发送 数据”。那么排除发送数据的大小，基本确定，在收集数据上花的时间较长
3. 优化方案
根据sql，它要查询相同userid，status下的最近的登录记录，distinct by userid,status=0才22条，虽然用了索引，但是还是查询收集1千700万多条数据，有效发送数据才22条，所以这个不是效率最高索引，故创建复合二叉树索引（userid，status，lastaccess）
4. 查看优化后的效果
效率杠杠的
5. 总结
咱们大致说一下仅仅关于Mysql的一个优化思路：
1. 检查slow.log，通过mysqldumpslow 分析一下排名sql
2. 分析执行计划，查看表的状态，索引等信息
3. 分析执行过程，与配置文件信息一同查看分析
