性能分析

# 统计表、索引 大小
SELECT ISS.SCHEMA_NAME AS "Schema_Name",
ITS.TABLE_NAME AS "Table_Name",
(ITS.DATA_LENGTH / 1024 / 1024) AS "Data(MB)",
(ITS.INDEX_LENGTH / 1024 / 1024) AS "Index(MB)",
((ITS.DATA_LENGTH + ITS.INDEX_LENGTH) / 1024 / 1024) AS "Data+Index(MB)",
ITS.TABLE_ROWS AS "Total_Rows"
FROM `information_schema`.`TABLES` ITS RIGHT JOIN
`information_schema`.`SCHEMATA` ISS
ON ITS.TABLE_SCHEMA = ISS.SCHEMA_NAME
WHERE ISS.SCHEMA_NAME LIKE "x%"
ORDER BY 4 DESC, ISS.SCHEMA_NAME, ITS.TABLE_NAME;

MySQL Optimization

MySQL 数 据库是常见的两个瓶颈是 CPU 和 IO 的瓶颈,CPU 在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候。磁盘 IO 瓶颈发生在装入数据远大于内 存容量的时候,如果应用分布在网络上,那么查询量相当大的时候那么平瓶颈就会出现在网络上,我们可以用 mpstat, iostat, sar 和 vmstat 来查看系统的性能状态。除了服务器硬件的性能瓶颈,对于 MySQL 系统本身,我们可以使用工具来优化数据库的性能,通常有三种:使用索引,使用 EXPLAIN 分析查询以及调整 MySQL 的内部配置。

Reference

性能瓶颈定位

Show

我们可以通过 show 命令查看 MySQL 状态及变量,找到系统的瓶颈:

Mysql> show status ——显示状态信息(扩展show status like 'XXX')
Mysql> show variables ——显示系统变量(扩展show variables like 'XXX')
Mysql> show innodb status ——显示InnoDB存储引擎的状态
Mysql> show processlist ——查看当前SQL执行,包括执行状态、是否锁表等
Shell> mysqladmin variables -u username -p password——显示系统变量
Shell> mysqladmin extended-status -u username -p password——显示状态信息

查看状态变量及帮助:

Shell> mysqld --verbose --help [|more #逐行显示]

慢查询日志

日志开启

在配置文件 my.cnf 或 my.ini 中在[mysqld]一行下面加入两个配置参数

log-slow-queries=/data/mysqldata/slow-query.log
long_query_time=2

log-slow-queries 参数为慢查询日志存放的位置,一般这个目录要有 mysql 的运行帐号的可写权限,一般都将这个目录设置为 mysql 的数据存放目录;long_query_time=2 中的 2 表示查询超过两秒才记录;在 my.cnf 或者 my.ini 中添加 log-queries-not-using-indexes 参数,表示记录下没有使用索引的查询。

log-slow-queries=/data/mysqldata/slow-query.log
long_query_time=10
log-queries-not-using-indexes

我们可以通过命令行设置变量来即时启动慢日志查询。由下图可知慢日志没有打开,slow_launch_time=# 表示如果建立线程花费了比这个值更长的时间,slow_launch_threads 计数器将增加: 设置慢日志开启: MySQL 后可以查询 long_query_time 的值 。 为了方便测试,可以将修改慢查询时间为 5 秒。

日志分析

我们可以通过打开 log 文件查看得知哪些 SQL 执行效率低下

[root@localhost mysql]# more slow-query.log
# Time: 081026 19:46:34
# User@Host: root[root] @ localhost []
# Query_time: 11 Lock_time: 0 Rows_sent: 1 Rows_examined: 6552961
select count(*) from t_user;

从日志中,可以发现查询时间超过 5 秒的 SQL,而小于 5 秒的没有出现在此日志中。如果慢查询日志中记录内容很多,可以使用 mysqldumpslow 工具(MySQL 客户端安装自带)来对慢查询日志进行分类汇总。mysqldumpslow 对日志文件进行了分类汇总,显示汇总后摘要结果。进入 log 的存放目录,运行

[root@mysql_data]#mysqldumpslow slow-query.log
Reading mysql slow query log from slow-query.log
Count: 2 Time=11.00s (22s) Lock=0.00s (0s) Rows=1.0 (2), root[root]@mysql
select count(N) from t_user;

mysqldumpslow 命令

/path/mysqldumpslow -s c -t 10 /database/mysql/slow-query.log

这会输出记录次数最多的 10 条 SQL 语句,其中:

  • -s, 是表示按照何种方式排序,c、t、l、r 分别是按照记录次数、时间、查询时间、返回的记录数来排序,ac、at、al、ar,表示相应的倒叙;

  • -t, 是 top n 的意思,即为返回前面多少条的数据;

  • -g, 后边可以写一个正则匹配模式,大小写不敏感的;

    例如:

/path/mysqldumpslow -s r -t 10 /database/mysql/slow-log

得到返回记录集最多的 10 个查询。

/path/mysqldumpslow -s t -t 10 -g “left join” /database/mysql/slow-log

得到按照时间排序的前 10 条里面含有左连接的查询语句。使用 mysqldumpslow 命令可以非常明确的得到各种我们需要的查询语句,对 MySQL 查询语句的监控、分析、优化是 MySQL 优化非常重要的一 步。开启慢查询日志后,由于日志记录操作,在一定程度上会占用 CPU 资源影响 mysql 的性能,但是可以阶段性开启来定位性能瓶颈。

Explain 分析查询

使用 EXPLAIN 关键字可以模拟优化器执行 SQL 查询语句,从而知道 MySQL 是如何处理你的 SQL 语句的。这可以帮你分析你的查询语句或是表结构的性能瓶颈。通过 explain 命令可以得到:

– 表的读取顺序

– 数据读取操作的操作类型

– 哪些索引可以使用

– 哪些索引被实际使用

– 表之间的引用

– 每张表有多少行被优化器查询

EXPLAIN 字段:

ØTable:显示这一行的数据是关于哪张表的

Øpossible_keys:显示可能应用在这张表中的索引。如果为空,没有可能的索引。可以为相关的域从 WHERE 语句中选择一个合适的语句

Økey:实际使用的索引。如果为 NULL,则没有使用索引。MYSQL 很少会选择优化不足的索引,此时可以在 SELECT 语句中使用 USE INDEX(index)来强制使用一个索引或者用 IGNORE INDEX(index)来强制忽略索引

Økey_len:使用的索引的长度。在不损失精确性的情况下,长度越短越好

Øref:显示索引的哪一列被使用了,如果可能的话,是一个常数

Ørows:MySQL 认为必须检索的用来返回请求数据的行数

Øtype:这是最重要的字段之一,显示查询使用了何种类型。从最好到最差的连接类型为 system、const、eq_reg、ref、range、index 和 ALL

nsystem、const:可以将查询的变量转为常量. 如 id=1; id 为 主键或唯一键.

neq_ref:访问索引,返回某单一行的数据.(通常在联接时出现,查询使用的索引为主键或惟一键)

nref:访问索引,返回某个值的数据.(可以返回多行) 通常使用=时发生

nrange:这个连接类型使用索引返回一个范围中的行,比如使用>或<查找东西,并且该字段上建有索引时发生的情况(注:不一定好于 index)

nindex:以索引的顺序进行全表扫描,优点是不用排序,缺点是还要全表扫描

nALL:全表扫描,应该尽量避免

ØExtra:关于 MYSQL 如何解析查询的额外信息,主要有以下几种

nusing index:只用到索引,可以避免访问表.

nusing where:使用到 where 来过虑数据. 不是所有的 where clause 都要显示 using where. 如以=方式访问索引.

nusing tmporary:用到临时表

nusing filesort:用到额外的排序. (当使用 order by v1,而没用到索引时,就会使用额外的排序)

nrange checked for eache record(index map:N):没有好的索引.

Profiling 分析查询

通过慢日志查询可以知道哪些 SQL 语句执行效率低下,通过 explain 我们可以得知 SQL 语句的具体执行情况,索引使用等,还可以结合 show 命令查看执行状态。

如果觉得 explain 的信息不够详细,可以同通过 profiling 命令得到更准确的 SQL 执行消耗系统资源的信息。

profiling 默认是关闭的。可以通过以下语句查看

打开功能: mysql>set profiling=1; 执行需要测试的 sql 语句:

mysql> show profiles\G; 可以得到被执行的 SQL 语句的时间和 ID

mysql>show profile for query 1; 得到对应 SQL 语句执行的详细信息

Show Profile 命令格式:

SHOW PROFILE [type [, type] … ]

[FOR QUERY n]
[LIMIT row_count [OFFSET offset]]

type:

ALL

| BLOCK IO

| CONTEXT SWITCHES

| CPU

| IPC

| MEMORY

| PAGE FAULTS

| SOURCE

| SWAPS

以上的 16rows 是针对非常简单的 select 语句的资源信息,对于较复杂的 SQL 语句,会有更多的行和字段,比如 converting HEAP to MyISAM 、Copying to tmp table 等等,由于以上的 SQL 语句不存在复杂的表操作,所以未显示这些字段。通过 profiling 资源耗费信息,我们可以采取针对性的优化措施。

测试完毕以后 ,关闭参数:mysql> set profiling=0

profiling 可以 查看 CPU、DISK I\O 等信息,这些很关键

临时表

在处理请求的某些场景中,服务器创建内部临时表。即表以 MEMORY 引擎在内存中处理,或以 MyISAM 引擎储存在磁盘上处理.如果表过大,服务器可能会把内存中的临时表转存在磁盘上。

临时表被创建几种情况

如果group by 的列没有索引,必产生内部临时表  

mysql> explain select goods_id,cat_id from goods group by cat_id \G ******************* 1. row ******************* id: 1 select_type: SIMPLE table: goods type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 20 Extra: Using temporary; Using filesort 1 row in set (0.00 sec)

mysql> alter table goods add index cat_id(cat_id); Query OK, 0 rows affected (0.18 sec) Records: 0 Duplicates: 0 Warnings: 0

mysql> explain select goods_id,cat_id from goods group by cat_id \G ******************* 1. row ******************* id: 1 select_type: SIMPLE table: goods type: index possible_keys: NULL key: cat_id key_len: 2 ref: NULL rows: 20 Extra: Using index

如果order by 与group by为不同列时,或多表联查时order by ,group by 包含的列不是第一张表的列,将会产生临时表

explain select goods_id,cat_id from goods group by cat_id order by 1 \G ******************* 1. row ******************* id: 1 select_type: SIMPLE table: goods type: index possible_keys: NULL key: PRIMARY key_len: 3 ref: NULL rows: 20 Extra: Using temporary

distinct 与order by 一起使用可能会产生临时表

mysql> explain select distinct cat_id from goods order by 1 \G ******************* 1. row ******************* id: 1 select_type: SIMPLE table: goods type: index possible_keys: NULL key: cat_id key_len: 2 ref: NULL rows: 20 Extra: Using index 1 row in set (0.00 sec)

mysql> explain select distinct cat_id from goods order by goods_id \G ******************* 1. row ******************* id: 1 select_type: SIMPLE table: goods type: index possible_keys: NULL key: PRIMARY key_len: 3 ref: NULL rows: 20 Extra: Using temporary 1 row in set (0.00 sec) mysql> explain select distinct cat_id from goods order by click_count\G ******************* 1. row ******************* id: 1 select_type: SIMPLE table: goods type: index possible_keys: NULL key: cat_id key_len: 2 ref: NULL rows: 20 Extra: Using temporary; Using filesort 1 row in set (0.00 sec)

备注:
1、想确定查询是否需要临时表,可以用EXPLAIN查询计划,并查看Extra列,看是否有Using temporary。
2、如果一开始在内存中产生的临时表变大,会自动转化为磁盘临时表。 内存中临时表的最大值为tmp_table_size和max_heap_size中较小值。