对MySQL的sql查询进行性能分析主要有两种方式：
- 分析整个数据库服务器，这样可以找到哪些查询是主要的压力来源。
- 定位具体需要优化的查询后，可以对这些查询进行单独的剖析，分析哪些子任务是影响时间的主要消耗者。
1.mysql 开启慢查询日志
#是否开启慢查询日志，1/on表示开启，0/off表示关闭
SHOW VARIABLES like 'slow_query_log';
#未使用索引的查询也被记录到慢查询日志中，on表示开启，off表示关闭
SHOW VARIABLES like 'log_queries_not_using_indexes';
#慢查询阈值（秒级），当查询时间大于设定的阈值时，记录日志
SHOW VARIABLES like 'long_query_time';
#慢查询日志存储路径
SHOW VARIABLES like 'slow_query_log_file';1.1 mysqldumpslow工具：mysql自带工具可以直接使用
-s, 是表示按照何种方式排序
c: 访问计数
l: 锁定时间
r: 返回记录
t: 查询时间
al:平均锁定时间
ar:平均返回记录数
at:平均查询时间
-t, 是top n的意思，即为返回前面多少条的数据；
-g, 后边可以写一个正则匹配模式，大小写不敏感的；例如：
#得到返回记录集最多的10个SQL
mysqldumpslow -s r -t 10 /tmp/mysql-slow.log
#得到查询次数最多的10个SQL
mysqldumpslow -s c -t 10 /tmp/mysql-slow.log
#得到查询次数最多，查询中包含“select”的10个SQL
mysqldumpslow -s c -t 10 -g "select" /tmp/mysql-slow.log1.2 pt-query-digest工具（第三方工具）很重要的一个mysql性能分析工具
1.下载安装工具；
wget percona.com/get/pt-query-digest2.授予用户执行权限；
chmod u+x pt-query-digest4.安装与Perl相关的模块；
yum install perl-DBI
yum install perl-Digest-MD5常用命令：
#分析慢查询日志中SQL的统计结果
pt-query-digest /tmp/mysql-slow.log | more
#分析select语句统计结果
pt-query-digest --filter '$event->{fingerprint} =~ m/^select/i' /tmp/mysql-slow.log | more
#查询指定用户(root)访问的查询
pt-query-digest --filter '($event->{user}) =~ m/^root/i' /tmp/mysql-slow.log | more
#分析所有全表扫描语句的统计结果
pt-query-digest --filter '(($event->{Full_scan} || "") eq "yes")' /tmp/mysql-slow.log | more
#分析所有Full join语句的统计结果
pt-query-digest --filter '(($event->{Full_join} || "") eq "yes")' /tmp/mysql-slow.log | more
#通过tcpdump抓取mysql的tcp协议数据，然后再分析
tcpdump -s 65535 -x -nn -q -tttt -i any -c 1000 port 3306 > mysql.tcp.txt在这里简要的介绍下pt-query-digest /tmp/mysql-slow.log | more 命令
执行 pt-query-digest 日志路径 | more
1.3 第一部分：总体统计结果
| Exec time | Lock time | Rows sent | Rows examine | Query size |
| 执行时间 |
锁定时间 |
发送行数 |
扫描行数 |
查询字符数 |
1.4 第二部分：查询分组统计结果
| Rank | 所有语句的排名，默认按查询时间降序排列，通过--order-by指定 |
| Query ID | 语句的ID，（去掉空格和查询条件中的文本值，计算hash值） |
| Response | 总的响应时间 |
| time | 该查询在本次分析中总的时间占比 |
| calls | 执行次数，即本次分析总共有多少条这种类型的查询语句 |
| R/Call | 平均每次执行的响应时间 |
| V/M | 方差均值比（Variance-to-mean），也就是常说的离差指数。 |
| 最后一列 | 查询对象 |
1.5 第三部分：每一种查询的详细统计结果
查询各项数据的百分比、总数、最小、最大、平均、95%等各项目的统计，包括SQL执行次数、执行时间、锁占用时间、发送行数、扫描行数、查询字符数，表格中也统计了查询涉及的数据库、查询时间直方图(Query_time distribution)等信息。
Rows Examine(扫描的行数越大磁盘IO越大）
Rows sent(发送的行数)
如果扫描的行数远远大于发送的行数说明可优化的空间很大
总结：
通过pt-query-digest工具可以分析出需要优化的SQL
一般查询次数较多且每次查询占用时间长的SQL；
IO大的SQL（也就是扫描行比发送行多很多的）未使用索引的SQL
2. 单条SQL分析：SHOW PROFILE
SHOW PROFILE命令是在MySQL5.1以后的版本中引入的，来源于开源社区中的Jeremy Cole的贡献。该工具默认是禁用的， 可以通过 SET profiling = 1; 修改开启：这个命令是针对一个session的需要执行sql后在执行这个命令才能看到
#查看开启工具后的每条SQL执行总体情况：show PROFILE；
#根据query_id查看某个查询的详细时间耗费：SHOW PROFILE FOR QUERY 1;
#对每一个子任务的花费时间进行已统计排序：
SELECT state, SUM(duration) AS Total_R,
ROUND(100 * SUM(duration) / (SELECT SUM(duration) FROM information_schema.profiling WHERE query_id = 1), 2) AS Pct_R,
COUNT(*) as Calls, SUM(duration) /COUNT(*) AS "R/Call"
FROM information_schema.profiling
WHERE query_id = 1 GROUP BY state ORDER BY total_r DESC;
| Creating sort index | Sending data | table lock | System lock | Sorting result | copying to tmp table | Creating tmp table |
| 当前的SELECT中需要用到临时表在进行ORDER BY排序。建议：创建适当的索引 | 发送数据 | 表锁 | 系统锁。建议确认是由于哪个锁引起的，通常是因为MySQL或InnoDB内核级的锁引起的 | 结果的排序 | 将数据复制到临时表 | 创建临时表 |
3. explain(执行计划)
3.1：执行计划各个字段代表的意思：(type:查询类型，key：使用的索引，Extra）为重要部分
Extra：
Using index：列数据仅仅使用了索引中的信息而没有读取实际的表
Using where：MySQL服务器将在存储引擎检索行后，通过Where子句条件进行过滤
Using temporary：MYSQL需要创建一个临时表来存储结果，用于排序
Using filesort：MySQL将对结果进行外部排序
| table | type | possible_keys | key | key_len | rows | Extra |
| 对应的表 |
连接类型（system、const、eq_ref、ref、range、index、all） |
可能使用的索引 | 实际使用的索引 |
使用索引长度 |
预计扫描行数 | 解析查询的额外信息（using index、using where、using temporary、using filesort） |
EXPLAIN SELECT id from company;3.2：Extra： 全索引扫描
EXPLAIN SELECT id from company
MySQL执行计划的局限
- EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况
- EXPLAIN不考虑各种Cache
- EXPLAIN不能显示MySQL在执行查询时所作的优化工作
- 部分统计信息是估算的，并非精确值
- EXPALIN只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划
