mysq常用l性能分析方法

1. orzdba查看读写
   ./orzdba.pl --mysql -S /data/mysql30001/mysql.sock 语句查看读写命令数量，以及数据库TPS，传输的大小
   
   
   
2. 查看processlist及其state
   mysql -uroot -p -S /data/mysql30001/mysql.sock, 密码sitMysql
   或者
    mysql -usa_test -pymtcs@2016 -S  /data/mysql30001/mysql.sock 
   
    select * from information_schema.processlist; 
    show processlist; 该语句不显示全部语句
    

查看当前进程的SQL语句，注意其STATE （以下一段引用百度）

在processlist中，看到哪些运行状态时要引起关注，主要有下面几个：
状态    建议    
copy to tmp table    执行ALTER TABLE修改表结构时 建议： 放在凌晨执行或者采用类似pt-osc工具    
Copying to tmp table    拷贝数据到内存中的临时表，常见于GROUP BY操作时 建议： 创建适当的索引    
Copying to tmp table on disk    临时结果集太大，内存中放不下，需要将内存中的临时表拷贝到磁盘上，形成 #sql***.MYD、#sql***.MYI(在5.6及更高的版本，临时表可以改成InnoDB引擎了，可以参考选项 default_tmp_storage_engine ) 建议： 创建适当的索引，并且适当加大 sort_buffer_size/tmp_table_size/max_heap_table_size    
Creating sort index    当前的SELECT中需要用到临时表在进行ORDER BY排序 建议： 创建适当的索引    
Creating tmp table    创建基于内存或磁盘的临时表，当从内存转成磁盘的临时表时，状态会变成：Copying to tmp table on disk 建议： 创建适当的索引，或者少用UNION、视图(VIEW)之类的    
Reading from net    表示server端正通过网络读取客户端发送过来的请求 建议： 减小客户端发送数据包大小，提高网络带宽/质量    
Sending data    从server端发送数据到客户端，也有可能是接收存储引擎层返回的数据，再发送给客户端，数据量很大时尤其经常能看见备注：Sending Data不是网络发送，是从硬盘读取，发送到网络是Writing to net 建议： 通过索引或加上LIMIT，减少需要扫描并且发送给客户端的数据量    
Sorting result    正在对结果进行排序，类似Creating sort index，不过是正常表，而不是在内存表中进行排序 建议： 创建适当的索引    
statistics    进行数据统计以便解析执行计划，如果状态比较经常出现，有可能是磁盘IO性能很差建议： 查看当前io性能状态，例如iowait    
Waiting for global read lock    FLUSH TABLES WITH READ LOCK整等待全局读锁 建议： 不要对线上业务数据库加上全局读锁，通常是备份引起，可以放在业务低谷期间执行或者放在slave服务器上执行备份    
Waiting for tables,Waiting for table flush    FLUSH TABLES, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, OPTIMIZE TABLE等需要刷新表结构并重新打开 建议： 不要对线上业务数据库执行这些操作，可以放在业务低谷期间执行    
Waiting for lock_type lock    
等待各种类型的锁：• Waiting for event metadata lock• Waiting for global read lock
• Waiting for schema metadata lock
• Waiting for stored function metadata lock
• Waiting for stored procedure metadata lock
• Waiting for table level lock
• Waiting for table metadata lock
• Waiting for trigger metadata lock
建议：比较常见的是上面提到的global read lock以及table metadata lock，建议不要对线上业务数据库执行这些操作，可以放在业务低谷期间执行。如果是table level lock，通常是因为还在使用MyISAM引擎表，赶紧转投InnoDB引擎吧
 

综上，查询中有Creat sort index就是有问题，可以优化，
原语句为 

SELECT FavoriteId, UserId, SourceId, AddTime, Type, SellerId, ProductId 
FROM `App_UserFavorite` 
WHERE `Userid` = 20000215 and `AddTime` < '2017-03-22 11:42:14.893' order by `FavoriteId` desc limit 10

优化为

explain SELECT FavoriteId, UserId, SourceId, AddTime, Type, SellerId, ProductId 
FROM `App_UserFavorite` 
WHERE `Userid` = 20000215 and `AddTime` < '2017-03-22 11:42:14.893' order by `AddTime` desc limit 10
优化后就没有 Creat sort index

3. 查看执行计划 explain
示例： 

explain SELECT FavoriteId, UserId, SourceId, AddTime, Type, SellerId, ProductId 
FROM `App_UserFavorite` 
WHERE `Userid` = 20000215 and `AddTime` < '2017-03-22 11:42:14.893' order by `FavoriteId` desc limit 10

详细Extra：

Using index condition; Using where; Using filesort

explain SELECT FavoriteId, UserId, SourceId, AddTime, Type, SellerId, ProductId 
FROM `App_UserFavorite` 
WHERE `Userid` = 20000215 and `AddTime` < '2017-03-22 11:42:14.893' order by `AddTime` desc limit 10;

对比两条语句的执行计划，发现第一条的Extra中用到东西多于第二条语句。
 Explain具体分析查看：  Mysql执行计划EXPLAIN详解 

4. mysql profile 调试sql

(1) 打开profile
set profile on
set session profiling=1;

（2）执行相关语句，例如 ：

SELECT FavoriteId, UserId, SourceId, AddTime, Type, SellerId, ProductId 
FROM `App_UserFavorite` 
WHERE `Userid` = 20000215 and `AddTime` < '2017-03-22 11:42:14.893' order by `FavoriteId` desc limit 10;

（3）查看profile队列中的语句
show profiles

对应的QueryId是28

（4）查看具体消耗
show profile for query 28; //28为QueryId
 

可以看出具体时间消耗

5. 查找慢查询
select * from mysql.slow_log  where start_time   >'2017-3-22 16:50:20' 
mysql.slow_log中会放所有慢查询语句，所以需要 用start_time筛选下。找到慢查询语句，就可以用3,4的方法分析。

6.  SPIN_Lock监控

当mysql的并发大时出现性能瓶颈，应用程序并发从1开始加到100的情况，应用每次请求会从Mysql拿下数据，下图是Mysql服务器的CPU占用状况

可以看到SystemTime的占用很高，这种情况一般是Linux底层_spin_lock过高引起的，这种情况下，一般认为mysql已到瓶颈，增大并发，并不能提高TPS
_spin_lock是内核级的自旋锁，每个Mysql process都会申请_spin_lock，具体原理，还有待研究
监控_spin_lock方法
（1）安装perf工具
yum install perf

（2）查看mysql进程号
top

（3）监控
 perf top -p 3127