当生产数据量急剧增长后，很多SQL语句可能会开始暴露出性能问题。当面对一个有SQL性能问题的数据库时，应该从何处入手进行系统的分析，使得能够尽快定位到问题SQL处并尽快解决问题？
第一步：查看SQL执行频率
MySQL客户端连接成功后，通过show [session|global] status命令可以提供服务器状态信息。show [session|global] status可以根据需要加上参数“session”或者“global”来显示session级（当前连接）的统计结果和global级（自数据库上次启动至今）的统计结果。如果不写，默认使用session。
显示当前session所有参数的统计结果：
显示global级的所有参数的统计结果：
第二步：定位执行效率低的SQL语句
可以通过以下两种方式定位执行效率低的sql语句
1）慢查询日志：用--log-slow-querles[=file_name]选项启动时，mysql写一个包含所有执行时间超过long_query_time秒的sql语句的日志文件。
2）show processlist：慢日志查询在查询结束后才记录，所以在应用反映执行效率出现问题的时候查询慢查询日志并不能定位问题，可以使用show processlist命令查看当前mysql在进行的线程，包括线程的状态，是否锁表等，可以实时地查看sql的执行情况，同时对一些锁表操作进行优化。
第三步：explain分析执行计划
通过以上步骤查询到效率低的sql语句后，可以通过explain或者desc命令获取mysql如何执行select语句的信息，包括在select语句执行过程中表如何连接和连接的顺序。
查询sql语句的执行计划：
id：id相同表示加载表的顺序是从上到下；id不同id值越大，优先级越高，越先被执行；id有相同也有不同，id相同则从上到下顺序执行，id不同则id值越大越先被执行。
select_type：表示select的类型，有如下的常见取值：
table：展示这一行的数据是关于哪一张表的
type：显示的是访问类型，是较为重要的一个指标，可取值为：
key：
rows：扫描行的数量
extra：其他的额外的执行计划信息，在该列展示
第四步：show profile分析sql
Mysql从5.0.37版本开始增加了对show profiles 和show profile语句的支持，show profiles能够在做sql优化时帮助我们了解时间都耗费到哪里去了。
通过select @@profiling命令查看当前mysql是否开启profile：（1表示已经开启，可以通过set profiling=1命令开启，set profiling=0关闭）
随便执行几条sql语句：
再通过show profiles命令查看sql语句执行的耗时：
通过show profile for query query_id命令查看某条sql在执行过程中每个线程的状态和消耗的时间
注意：Sending data 状态便是mysql线程开始访问数据行并把结果返回给客户端，而不仅仅是返回给客户端，由于在Sending data状态下，mysql线程往往要坐大量的磁盘读取操作，所以经常是整个查询中耗时最长的状态。
在获取到最消耗时间的线程状态之后，mysql支持进一步选择all、cpu、block lo、context switch、page faults等明细类型查看mysql在使用什么资源上耗费了过高的时间，例如，选择查看cpu的耗费时间：
第五步：trace分析优化器执行计划
mysql5.6提供了对sql的跟踪trace，通过trace文件能够进一步了解为什么优化器选择A计划而不是选择B计划
打开trace。设置格式为json并设置trace最大能够使用的内存大熊啊，避免解析过程因为内存过小而不能够完整展示。
在执行完sql语句后，检查 information_schema.optimizer_trace就可以知道mysql是如何执行sql的。
