一、
第二部分
Calls：调用次数
R/Call:平均每次查询耗时情况 V/M：方差均值比
第三部分：详细SQL慢查询参数统计
Rows sent、Rows examine 差别越大，表示做了更多的无用功，索引利用效率差
二、线上数据库打开了慢查询日志记录功能的话，对数据库的性能影响大吗？
肯定有一定的影响，微弱，日志文件占用物理磁盘空间，
三、哪些SQL需要优化：
1、查询次数多，而且占用时间比较长的SQL
2、IO大的SQL：Rows examine数值比较大的SQL，（是否有必要？是否可以使用limit）
3、未使用索引或者索引利用率不高的SQL（pt-query-digest第三部分 Rows sent、Rows examine 差别大
四、BTree索引的有效利用与限制
索引生效的情况：
1、匹配最左前缀
2、全值匹配
3、匹配列前缀
4、匹配范围值
5、精确匹配某列并范围匹配另外一列
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
Like百分写最右，覆盖索引不写星；
不等空值还有or，索引失效要少用。
BTree索引的限制：
1、如果不是按照索引的最左列开始查找，则无法使用索引，
2、不能跳过索引中的列
3、如果查询中有某个列的范围查询，则其右边所有列都无法使用索引优化查找，
五、分析SQL低效的原因
1、explain
①索引利用情况
②排序
③临时表
④回表读行
⑤行扫描情况
2、Profiles SQL各个子任务资源消耗情况
六、修改索引
1、是否有无用的索引需要删除
2、是否可以适当建立组合索引
3、组合索引的顺序是否需要调整
4、前缀索引
5、覆盖索引的利用
七、重写SQL
1、是否因为列的计算导致索引失效
2、是否有不需要的列别查询：select *
3、是否有不适当的关联关系导致过多读行
4、是否可以将复杂的SQL拆分
5、是否可以指定使用更好的索引：USE Index