该篇主要讨论SQL及索引优化中的SQL优化
1.首先我们应该要思考如何发现有问题的SQL:通过慢查日志
慢查日志默认是关闭的,需要开启慢查日志
//开启slow_query_log之前查看log_queries_not_using_indexes,并设置为on
mysql> set global log_queries_not_using_indexes=on;
//设置long_query_time
mysql> set global long_query_time=1; //注意一定要exit再重新进入mysql才能显示生效
//设置slow_query_log为ON
mysql> set global slow_query_log=on;
开启慢查日志之后,符合条件的SQL查询就会记录到慢查日志文件中
//查看慢查询日志的存储位置
mysql> show variables like 'slow_query_log_file';
2.拿到慢查日志之后,如何来分析SQL:mysqldumpslow(mysql自带)和pt-query-digest(第三方)
MySQL慢查日志分析工具之mysqldumpslow
通过mysqldumpslow(mysql自带的)来分析前3最耗时的SQL操作
//-t 代表top n queries
shell> mysqldumpslow -t 3 /var/lib/mysql/mysql-slow.log | more; //(根据实际文件位置)
MySQL慢查日志分析工具之pt-query-digest
需要安装
因为pt-query-digest是 Percona Toolkit中的一部分,因此,选择安装整个Percona Toolkit, 详情见pt-query-digest
安装Percona Toolkit
a. Percona Toolkit不在Centos yum源中,添加进去,见Configuring Percona Repository on Red Hat Enterprise Linux and CentOS
shell> sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm
b. yum安装Percona Toolkit
shell> sudo yum install percona-toolkit
现在可以使用pt-query-digest了
shell> pt-query-digest --help //测试pt-query-digest命令是否可用
// 使用pt-query-digest分析慢查日志文件
shell> pt-query-digest /var/lib/mysql/mysql-slow.log | more;
其次如何通过慢查日志发现有问题的SQL?
- 查询次数多且每次查询占用时间长的SQL
通常为pt-query-digest分析的前几个查询 - IO大的SQL
注意pt-query-digest分析中的Rows examine项 - 未命中索引的SQL
注意pt-query-digest分析中的Rows examine和Rows Send的对比
3.通过慢查日志获取到有问题的SQL之后,通过explain查询来分析SQL
explain返回各列的定义
- table: 显示这一行的数据是关于哪张表的
- type:这是重要的列,显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL
- possible_keys: 显示可能应用在这种表中的索引。如果为空,没有可能的索引
- key: 实际使用的索引。如果为NULL,则没有使用索引
- key_len: 使用的索引的长度。在不损失精确性的情况下,长度越短越好
- ref: 显示索引的哪一列被使用了, 如果可能的话,是一个常数
- rows:MYSQL认为必须检查的用来返回请求数据的行数
- extra:需要注意的返回值
- Using filesort:看到这个的时候,查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
- Using temporary: 看到这个的时候,查询需要优化了。这里,MYSQL需要创建一个临时表来存储结果,这通常发生在对不同的列集进行order by上,而不是group by上