如何定位 问题SQL的【一般套路】

拿到了一个运行了一段时间的mysql数据库, 该如何进行系统的分析, 尽快的定位问题SQL并解决呢?

一 首先,通过show status命令了解一下当前数据库各种SQL执行的频率.                                           

  格式：mysql> show [session|global] status;

  其中：session（默认）表示当前连接，  global表示自数据库启动至今

mysql>show status;

mysql>show global status;

mysql>show status like ‘Com_%’;

mysql>show global status like ‘Com_%’;

        

参数说明：

Com_XXX表示每个XXX语句执行的次数如：

Com_select 执行select操作的次数，一次查询只累计加1

Com_update 执行update操作的次数

Com_insert 执行insert操作的次数，对批量插入只算一次。

Com_delete 执行delete操作的次数

只针对于InnoDB存储引擎的。

InnoDB_rows_read 执行select操作的次数

InnoDB_rows_updated 执行update操作的次数

InnoDB_rows_inserted 执行insert操作的次数

InnoDB_rows_deleted 执行delete操作的次数

其他：

connections 连接mysql的数量

Uptime 服务器已经工作的秒数

Slow_queries: 慢查询的次数

通过以上操作可以比较容易的了解当前数据库是以插入更新为主还是查询为主, 以及各种类型sql大致的执行比例, 先稍微有个全局的了解

二 其次, 定位执行效率较低的SQL语句                                                                                                                                        

定位效率低下的sql方法主要有两种, 

1.设置mysql的慢查询日志, 说白了就是打开mysql的 记录执行比较慢的sql的日志功能.

【mysql 5.6 为以下配置】on 打开日志开关, 记录执行时间超过2秒的, 日志记录位置在slow_query.log 中

slow_query_log = ON
slow_launch_time = 2
slow_query_log_file = /usr/local/mysql/data/slow_query.log

【5.6以前】的配置为:   long_query_time=时间(秒)和log-slow-queries=文件路径

在应用运行一段时间后, 就可以打开慢查询日志进行分析了.

2.可以使用SHOW PROCESSLIST; 或SHOW FULL PROCESSLIST; 命令查看当前mysql在进行的线程,包括线程的状态, 是否锁表等.

  

id列 ，不用说了吧，一个标识，你要kill一个语句的时候很有用。

user列，显示单前用户，如果不是root，这个命令就只显示你权限范围内的sql语句。

host列，显示这个语句是从哪个ip的哪个端口上发出的，可以用来追踪出问题语句的用户。

db列，显示这个进程目前连接的是哪个数据库。

command列，显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect）。

time列，此这个状态持续的时间，单位是秒。

state列，显示使用当前连接的sql语句的状态，很重要的列，后续会有所有的状态的描述，请注意，state只是语句执行中的某一个状态，一个sql语句，已查询为例，可能需要经过copying to tmp table，Sorting result，Sending data等状态才可以完成，

info列，显示这个sql语句，因为长度有限，所以长的sql语句就显示不全, 这时候就可以使用SHOW FULL PROCESSLIST ; 让其显示全

State字段可能为以下这几种值: 标红的为需要注意一下,比较长出现的.

　Checking table  正在检查数据表（这是自动的）。

　Closing tables  正在将表中修改的数据刷新到磁盘中，同时正在关闭已经用完的表。这是一个很快的操作，如果不是这样的话，就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。

　Connect Out  复制从服务器正在连接主服务器。

　Copying to tmp table on disk 由于临时结果集大于tmp_table_size，正在将临时表从内存存储转为磁盘存储以此节省内存。

　Creating tmp table  正在创建临时表以存放部分查询结果。

　deleting from main table  服务器正在执行多表删除中的第一部分，刚删除第一个表。

　deleting from reference tables  服务器正在执行多表删除中的第二部分，正在删除其他表的记录。

　Flushing tables 正在执行FLUSH TABLES，等待其他线程关闭数据表。

　Killed  发送了一个kill请求给某线程，那么这个线程将会检查kill标志位，同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位，不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了，那么kill请求会在锁释放时马上生效。

　Locked  被其他查询锁住了。

　Sending data  正在处理Select查询的记录，同时正在把结果发送给客户端。 (如果这个状态持续时间很长,那么这个sql很大可能就是有问题的)

　Sorting for group  正在为GROUP BY做排序。

　Sorting for order  正在为ORDER BY做排序。

　Opening tables  这个过程应该会很快，除非受到其他因素的干扰。例如，在执Alter TABLE或LOCK TABLE语句行完以前，数据表无法被其他线程打开。正尝试打开一个表。

　Removing duplicates  正在执行一个Select DISTINCT方式的查询，但是MySQL无法在前一个阶段优化掉那些重复的记录。因此，MySQL需要再次去掉重复的记录，然后再把结果发送给客户端。

　Reopen table  获得了对一个表的锁，但是必须在表结构修改之后才能获得这个锁。已经释放锁，关闭数据表，正尝试重新打开数据表。

　Repair by sorting  修复指令正在排序以创建索引。

　Repair with keycache  修复指令正在利用索引缓存一个一个地创建新索引。它会比Repair by sorting慢些。

　Searching rows for update  正在讲符合条件的记录找出来以备更新。它必须在Update要修改相关的记录之前就完成了。

　Sleeping  正在等待客户端发送新请求.

　System lock  正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表，那么可以通过增加--skip-external-locking参数来禁止外部系统锁。

　Upgrading lock  Insert DELAYED正在尝试取得一个锁表以插入新记录。

　Updating  正在搜索匹配的记录，并且修改它们。

　User Lock  正在等待GET_LOCK()。

　Waiting for tables  该线程得到通知，数据表结构已经被修改了，需要重新打开数据表以取得新的结构。然后，为了能的重新打开数据表，必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知：FLUSH TABLES tbl_name, Alter TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。

　waiting for handler insert  Insert DELAYED已经处理完了所有待处理的插入操作，正在等待新的请求。

　大部分状态对应很快的操作，只要有一个线程保持同一个状态好几秒钟，那么可能是有问题发生了，需要检查一下。

   三 通过 EXPLAIN 分析较低效SQL的执行计划

通过上边两步确定了问题的sql, 那么就需要将具体的sql 拿出来,具体问题具体分析了, 为什么这个sql执行的效率低, 这时候就需要用到mysql 的explain 命令进行分析了.

 

mysql> explain select count(*) from stu where name like "a%"\G

*************************** 1. row ***************************

           id: 1

  select_type: SIMPLE

        table: stu

         type: range

possible_keys: name,ind_stu_name

          key: name

      key_len: 50

          ref: NULL

         rows: 8

        Extra: Using where; Using index

1 row in set (0.00 sec)

每一列的简单解释

id: 1

select_type: SIMPLE 表示select的类型，常见的取值有SIMPLE（简单表，即不使用表连接或者子查询）、PRIMARY（主查询，即外层的查询）、UNION（UNION中的第二个或者后面的查询语句）、SUBQUERY（子查询中的第一个SESECT）等

table: stu   输出结果集的表

type: 从上到下, 效率由最好到最差, all 需要遍历全表来匹配.

      range  表示表的连接类型，性能有好到差：

      system（表仅一行）、

      const（只一行匹配）、

      eq_ref（对于前面的每一行使用主键和唯一）、

      ref（同eq_ref，但没有使用主键和唯一）、

      ref_or_null（同前面对null查询）、

      index_merge（索引合并优化）、

      unique_subquery（主键子查询）、

      index_subquery（非主键子查询）、

      range（表单中的范围查询）、

      index（都通过查询索引来得到数据）、

      all（通过全表扫描得到的数据）

possible_keys:  name,ind_stu_name  表查询时可能使用的索引。

key: name   表示实际使用的索引。

key_len: 50  索引字段的长度

ref: NULL

rows: 8   扫描行的数量

Extra: Using where; Using index 执行情况的说明和描述

通过explain extended命令 加上show warnings 命令, 我们还可以看到sql真正被执行前优化器做了哪些sql的改写.

通过不断的改写sql和使用explain 分析, 来优化sql ,达到提醒sql执行效率的问题.

如果explain 搞不定,还可以使用show profile

四. 通过show profile 分析SQL的执行效率.                                

  

通过profile, 我们可以很清楚的了解SQL的执行过程. 

1 先执行一个sql.

2 使用SHOW profiles; 看一下刚才执行的sql的 Query_ID是多少. 我这里是60

3 SHOW profile FOR QUERY 60; 看一下这个sql执行过程中, 各个部分的执行时间是多少.那个状态最耗时.

一般情况下,处在Sending data状态下,mysql线程往往需要做大量的磁盘IO操作, 所以经常这个状态是最耗时的.

总结:通过以上几个步骤, 该加索引加索引, 该调整语句结构就调整, 该杀进程杀进程.