网上都是PMM Percona Monitoring and Management的安装部署文章，今天我出一个使用PMM的教学文章，寻找数据库负载最高的语句例子。
一、 问题 PMM Query Analytics 的查询分析器使用方法
二、下面用一个例子来介绍查询分析器的使用方法，介绍各个参数的意思。先上图
这个图意思是：我选择了 2 天取样时间，对 load 进行排序，选择一条 sql 语句，这条 sql 语句每秒执行 3.41 次， 2 天时间里总共执行了 589970 次， sql 负载占整个 sql 的负载是 80% 。这个是很高很高的了。
如上图，我选择了 sql 语句
select member0_.id as id2_166_, member0_.createdDate as createdD3_166_, member0_.lastModifiedDate as lastModi4_166_, member0_.version as version5_166_, member0_.isEnabled as isEnable6_166_, member0_.isLocked as isLocked7_166_, member0_.lastLoginDate as lastLogi8_166_, member0_.lastLoginIp as lastLogi9_166_, member0_.lockDate as lockDat10_166_, member0_.mobile as mobile11_166_, member0_.operatorNo as operato12_166_, member0_.address as address57_166_, member0_.amount as amount58_166_, member0_.area_id as area_id67_166_, member0_.attributeValue0 as attribu18_166_, member0_.attributeValue1 as attribu19_166_, member0_.attributeValue2 as attribu30_166_, member0_.attributeValue3 as attribu31_166_, member0_.attributeValue4 as attribu32_166_, member0_.attributeValue5 as attribu33_166_, member0_.attributeValue6 as attribu34_166_, member0_.attributeValue7 as attribu35_166_, member0_.attributeValue8 as attribu36_166_, member0_.attributeValue9 as attribu37_166_, member0_.balance as balance38_166_, member0_.birth as birth59_166_, member0_.commissionBalance as commiss60_166_, member0_.email as email14_166_, member0_.encodedPassword as encoded15_166_, member0_.frozenAmount as frozenA42_166_, member0_.frozenCommissionBalance as frozenC61_166_, member0_.gender as gender62_166_, member0_.headimgurl as headimg63_166_, member0_.memberRank_id as memberR68_166_, member0_.name as name16_166_, member0_.nickname as nicknam64_166_, member0_.phone as phone52_166_, member0_.point as point65_166_, member0_.safeKeyExpire as safeKey53_166_, member0_.safeKeyValue as safeKey54_166_, member0_.username as usernam17_166_, member0_.zipCode as zipCode66_166_ from Users member0_ where member0_.dtype= ？ and member0_.operatorNo= ？ 得到了下面表格的一些计算数据：
三、 名称解释
query time ： 这里的 query time 和 mysql 的慢日志里面query time 两个概念是一样的吗？ 答案是：2个概念是不一样的。这个是什么意思呢？这个 query time , 是这条语句总共执行了 9 days,11:25:15 这么长时间，总共执行了 589.97k 次，得到的平均执行时间是 817200/589970=1.39 sec 。这里有个奇怪的问题是，我取样的时间是 2days, 仔细看图，为什么这条语句执行时间是 9 天又 11 个小时呢？这里埋个问题。
Load ：这里的 load 我没有真正看出来了含义，表示 sql 执行时间的负载。这里要注意 sql 负载占比百分比才有意义。这条 sql 语句占比 80% ，说明数据库大部分时间用于执行这条语句。
Query count ：执行次数，本条语句执行 589970 次， qps 是 3.41
Rows examined ：每次执行扫描的行数 473170, 为了执行这条语句，数据库每次需要扫描 473170 条记录才能得到这一条记录，哎呀，好累呀，计算机干活还是很卖力的，每次执行这条语句都要查询这么多记录。
query time 是这条语句的平均执行时间，慢日志查询的 query time 是本条语句当前执行时间。
发现这条语句有问题后，我去慢查询日志看， 慢查询日志有2G大，找到了慢日志sql：
四、现在开始优化这条语句。
看下现在执行计划：
这条语句用到了索引 key, 不过仍然很慢，执行时间需要 3 秒。检索了 40401 条记录。
看下这个表建立了哪些索引？
果然有 UKt3bl114953i5jey88j9rk472n 这个索引。
那为什么还是这么慢呢？这里思考 2 分钟接着往下看：
因为这个索引 (`dtype`,`username`) 能检索到的数据量还是比较大的，不够高效，用了这个索引还要检索40401条记录。那现在建立一个更加高效的索引：
create index idx_users_operatorno_2 on users(operatorNo,dtype);
这个时候你再来看执行计划：
看到没有，使用了我新建立的索引，检索数据变成 1 条，这样，再执行一下这条语句，就是 0.01 秒。好了问题解决。
四、 刚刚说的 PMM 的 query time 和慢查询的 query time 计算方法不一样，假如，如果，我需要方便的从 PMM 的界面得到 sql 语句一次查询的 query time，该怎么操作 呢？
答案：缩短取样时间。
五、
总结：用 PMM 查询分析，用 load 排序，可以找到负载最大的 sql ，优化这个 sql ，整个数据库的负载就下来了。为什么呀？其实你可以思考下，数据库是什么？可以这样理解：就是一个不停执行 sql 语句然后返回结果给用户的机器嘛，没有了慢查询 sql ，数据库负载降低，吞吐量就会提高，表现就会快嘛。