查看系统性能参数

在MySQL中，可以使用 SHOW STATUS 语句查询一些MySQL数据库服务器的性能参数、执行频率。 SHOW STATUS语句语法如下：

SHOW [GLOBAL|SESSION] STATUS LIKE '参数';

一些常用的性能参数如下：
• Connections：连接MySQL服务器的次数。
• Uptime：MySQL服务器的上线时间。
• Slow_queries：慢查询的次数。
• Innodb_rows_read：Select查询返回的行数
• Innodb_rows_inserted：执行INSERT操作插入的行数
• Innodb_rows_updated：执行UPDATE操作更新的行数
• Innodb_rows_deleted：执行DELETE操作删除的行数
• Com_select：查询操作的次数。
• Com_insert：插入操作的次数。对于批量插入的 INSERT 操作，只累加一次。
• Com_update：更新操作的次数。
• Com_delete：删除操作的次数。

慢查询日志

定位执行最慢的SQL
通过慢查询日志，可以查找出哪些查询语句的执行效率低，以便进行优化。
通俗的说，MySQL 慢查询日志是排查问题的 SQL 语句，以及检查当前 MySQL 性能的一个重要功能。如果不是调优需要，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。
可以通过 log-slow-queries 选项开启慢查询日志。通过 long_query_time 选项来设置时间值，时间以秒为单位。如果查询时间超过了这个时间值，这个查询语句将被记录到慢查询日志。

SELECT @@global.slow_query_log  #查看是否开启

1==>开启 0==>关闭

set global slow_query_log=1  #开启

SELECT @@[global,session].long_query_time  #查看慢查询阙值，默认10s

这个变量是全局和会话都有的

select @@global.slow_query_log_file  #产看慢查询日志输出文件

重置慢查询日志

mysqladmin -uroot -p flush-logs slow

flush-logs 表示刷新所有日志 ,加上 slow 之刷新慢查询日志

查看SQL的执行成本

SELECT @@session.profiling  #查看是否打开profile

1==>开启 0==>关闭

SHOW PROFILES  #查看最近的几条profile

SHOW PROFILE FOR QUERY 81   查看指定条的详细查询

explain 查看执行计划

MySQL 5.6.3以前只能 EXPLAIN SELECT ；
MYSQL 5.6.3以后就可以 EXPLAIN SELECT，UPDATE， DELETE 在5.7以前的版本中，想要显示 partitions 需要使用 explain partitions 命令；想要显示 filtered 需要使用 explain extended 命令。在5.7版本后，默认explain直接显示partitions和 filtered中的信息。

1. table
不论我们的查询语句有多复杂，里边儿包含了多少个表，到最后也是需要对每个表进行单表访问的，所以MySQL规定EXPLAIN语句输出的每条记录都对应着某个单表的访问方法，该条记录的table列代表着该表的表名（有时不是真实的表名字，可能是简称）。

id

我们写的查询语句一般都以 SELECT 关键字开头，比较简单的查询语句里只有一个 SELECT 关键字，比如下边这个查询语句：
```
SELECT * FROM s1 WHERE key1 = 'a';
```
稍微复杂一点的连接查询中也只有一个 SELECT 关键字，比如：
```
SELECT * FROM s1 INNER JOIN s2
ON s1.key1 = s2.key1
WHERE s1.common_field = 'a';
```
这样只有一个SQL语句的无论几张表 id 都是相同的，但是只有有多个Select，id值就将不同 ```javascript SELECT FROM s1 UNION SELECT FROM s2;

SELECT * FROM s1 WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field = ‘a’); ```

id如果相同，可以认为是一组，从上往下顺序执行
在所有组中，id值越大，优先级越高，越先执行
关注点：id号每个号码，表示一趟独立的查询, 一个sql的查询趟数越少越好

select_type

每个小查询的类型

简单的查询是 simple
包含 union 或 union all 或子查询的语句，最左边或最外边是 primary
对于 union 和 union all 最左边的是primary 其他的都是 union
对于子查询，不能被优化器优化为连接查询的话，且是不相关子查询==>subquery,是相关子查询 dependent subquery
对于包含派生表的查询，派生出来表的查询是derived

4.type
完整的访问方法如下： system ， const ， eq_ref ， ref ， fulltext ， ref_or_null ， index_merge ， unique_subquery ， index_subquery ， range ， index ， ALL 。越靠后的效率越低

结果值从最好到最坏依次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL 其中比较重要的几个提取出来，SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，最好是 consts级别。（阿里巴巴开发手册要求）
5. key_len
实际使用到的索引长度，字节数，主要针对联合索引，和自己（同一个索引）比越长越好

6.rows
预估需要读取的记录（越小越好）
7. filtered
摸个表经过条件字段过滤后的百分比
再连接查询中的意义更大，可以用来观察内表连接的次数
8. Extra
1、using filesort
如果在Extra字段中出现了using filesort，说明SQL性能消耗大，它表示需要额外的一次排序或查询，常见于order by语句中（需要优化）
2、using temporary
性能损耗大，用到了临时表。一般出现在group by 语句中。（需要优化）
3.Using join buffer (Block Nested Loop)
典型的，两个关联表join，关联字段均未建立索引，就会出现这种情况。常见的优化方案是，在关联字段上添加索引，避免每次嵌套循环计算。（需要优化）

索引优化

索引失效，没有充分利用索引—索引重建
关联查询太多join （设计缺陷）— SQL优化
服务器优化及各个参数设置（缓存，线程数等）— 调整my.cnf
数据太多—分库分表

索引性能分析

查看系统性能参数

慢查询日志

查看SQL的执行成本

explain 查看执行计划

索引优化