percona_pk_digest
一、性能优化
1、performanc_schema存储引擎/库
1、各种工具
--percona-toolkit(30多种工具） -oprofile -strace --tcpdump --show profiles ;show processlist;performance schema等 --new relic工具（待了解）p106
2、percona toolkit工具包中包含的工具；
（1）工具下载
https://www.percona.com/software/database-tools/percona-toolkit
（2）官方手册
https://docs.percona.com/percona-toolkit/index.html
（3）中文手册
https://download.topunix.com/MySQL/Software-tools/Percona-Toolkits/Percona%20%20Toolkit%CA%D6%B2%E1%A3%A8%D6%D0%CE%C4%B0%E6%A3%A9%A3%A8%CF%EA%CF%B8%CD%EA%D5%FB%A3%A9.pdf
pt-query-digest;
pt-stalk;
（1）show profiles的应用
设置启用：set profiling=1; 执行SQL语句：select count(*) from operationproject.operation_workorder; 查看当前会话执行的语句：show profiles;
查看某个sql的详细执行信息：
show profile for query 2;
（2）使用information_schema对应的表
利用上面的查询profiles;
set @query_id=1;
SELECT STATE, SUM( DURATION ) AS Total_R, ROUND( 100 * SUM( DURATION )/( SELECT SUM( DURATION ) FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID = @query_id ), 2 ) AS Pct_R, COUNT(*) AS Calls, SUM( DURATION ) / COUNT(*) AS "R/Call" FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID = @query_id GROUP BY STATE ORDER BY Total_R DESC;
（3）show status
（4）explain执行计划
二、间歇性问题
1、间歇性的问题：
间歇性的问题（比如系统偶尔停顿或者慢查询）很难诊断。
有些幻影问题只在没有注意到的时候才发生，而且无法确认如何重现，诊断这样的问题往往要花费很多时间，有时候甚至需要好几个月。
在这个过程中，有些人会尝试以不断试错的方式来诊断，有时候甚至会想要通过随机地改变一些服务器的设置来侥幸地找到问题。
尽量不要使用试错的方式来解决问题。 这种方式有很大的风险，因为结果可能变得更坏。
间歇性问题的几个案例：
--应用通过curl从一个运行得很慢的外部服务来获取汇率报价的数据。 --curl 是常用的命令行工具，用来请求 Web 服务器。它的名字就是客户端（client）的 URL 工具的意思 --memcached缓存中的一些重要条目过期，导致大量请求落到MySQL以重新生成缓存条目。 --DNS查询偶尔会有超时现象。 --可能是由于互斥锁争用，或者内部删除查询缓存的算法效率太低的缘故，MySQL的查询缓存有时候会导致服务有短暂的停顿。 --当并发度超过某个阈值时，InnoDB的扩展性限制导致查询计划的优化需要很长的时间。
从上面可以看到，有些问题确实是数据库的原因，也有些不是。只有在问题发生的地方通过观察资源的使用情况，并尽可能地测量出数据，才能避免在没有问题的地方耗费精力。
2、间隙性问题的解决思路
首先要确认这是单条查询的问题，还是服务器的问题。
--如果服务器上所有的程序都突然变慢，又突然都变好，每一条查询也都变慢了，那么慢查询可能就不一定是原因，而是由于其他问题导致的结果。 --如果服务器整体运行没有问题，只有某条查询偶尔变慢，就需要将注意力放到这条特定的查询上面。
3、间歇性问题判断
（1）判断单条查询问题还是服务器问题的方法1：show global status
这个方法实际上就是以较高的频率比如一秒执行一次SHOWGLOBALSTATUS命令捕获数据，问题出现时，则可以通过某些计数器的“尖刺”或者“凹陷”来发现。
这个方法比较简单，所有人都可以使用(不需要特殊的权限)，对服务器的影响也很小，所以是一个花费时间不多却能很好地了解问题的好方法。
mysqladmin -uroot -prootroot ext -i1|awk '/Queries/{q=$4-qp;qp=$4} /Threads_connected/{tc=$4} /Threads_running/{printf "%5d %5d %5d\n", q, tc, $4}'
（2）判断单条查询问题还是服务器问题的方法2：show processlist
这个方法是通过不停地捕获SHOW PROCESSLIST 的输出，来观察是否有大量线程处于不正常的状态或者有其他不正常的特征。
例如查询很少会长时间处于“statistics"状态，这个状态一般是指服务器在查询优化阶段如何确定表关联的顺序一通常都是非常快的。
另外，也很少会见到大量线程报告当前连接用户是 未经验证的用户(Unauthenticated user)，这只是在连接握手的中间过程中的状态，当客户端等待输入用于登录的用户信息的时候才会出现。
使用SHOW PROCESSLIST 命令时，在尾部加上\G可以垂直的方式输出结果，这很有用，因为这样会将每一行记录的每一列都单独输出为一行，这样可以方便地使用 sort|uniq|sort 一类的命令来计算某个列值出现的次数:
mysql -uroot -prootroot -e 'SHOW PROCESSLIST\G' | grep State: | sort | uniq -c | sort -rn
（3）判断单条查询问题还是服务器问题的方法3：使用查询日志
如果要通过查询日志发现问题，需要开启慢查询日志并在全局级别设置long_query_time为0,并且要确认所有的连接都采用了新的设置。
这可能需要重置所有连接以使新的全局设置生效
或者使用Percona Server的一个特性，可以在不断开现有连接的情况下动态地使设置强制生效。
如果因为某些原因，不能设置慢查询日志记录所有的查询，也可以通过tcpdump和pt-query- digest工具来模拟替代。
awk '/^# Time:/{print $3, $4, c;c=0}/^# User/{c++}' slow-query.log
4、捕获诊断数据
5、一个诊断案例
三、总结
1、explian中的type
结果值从最好到最坏依次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL 比较重要的包含：system、const 、eq_ref 、ref、range > index > ALL SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，最好是 consts级别。（阿里巴巴> 开发手册要求）
