高性能MySQL-服务器性能剖析

如***加粗样式***何确认服务器是否达到了性能最佳状态、找出某条语句为什么执行不够快，已经诊断被用户描述成“停顿”、“堆积”或者“卡死”的某些间歇性疑难故障

性能优化简介
1:将性能定义为完成某件任务所需要的时间度量，即性能即响应时间
2:假设性能优化是就是在一定工作负载下尽可能降低响应时间(不是CPU利用率)
3:无法测量就无法有效地优化(搞清楚时间花在哪里)
4:合适测量(不在错误时间启动和停止测量，测量的是聚合后的信息，而不是明白活动本身)
5:完成一项任务可以分成两个部分，执行时间和等待时间

通过性能剖析进行优化
1:性能剖析是测量和分析时间花费在那里的主要方法
2:一般两个步骤：测量任务所花费时间;然后对结果进行统计和排序，将重要的任务排到前面。
3:实际上的两种类型性能剖析：基于执行时间的分析和基于等待的分析
4:执行时间：研究是什么任务的执行时间最长。 等待时间：判断任务在什么地方被阻塞的时间最长
5:在对系统进行性能剖析前，必须先要能够进行测量，这需要系统可测量化的支持(5.5版本才第一次有提供performance schema，其中有一些基于时间的测量点)

理解性能剖析
MySQL性能剖析将最重要的任务展示在前面，但有时候没有显示出来其他重要信息
1:值得优化的查询(一些只占总响应很小的查询是不值得优化的，优化成本大于收益，不值得优化)
2:异常情况
3:未知的未知，一款好的性能剖析工具会显示可能的“丢失时间”，指任务总时间和实际测量到时间之间的差
4:被掩藏细节，性能分析无法显示所有响应时间的分布，pt-query-digest包含了有些细节
5:无法在更高层次的堆栈中进行交互式分析

对应用程序进行性能剖析
1:对任何需要消耗时间的任务都可以做性能剖析，当然包括应用程序 ，一般比数据库容易回报多
2:对系统进行性能剖析建议自上而下

可能影响因素
1:外部资源
2:应用需要处理大量数据
3:在循环中执行比较贵的算法
4:使用了低效算法

3:建议在新项目中都考虑包含性能剖析的代码
4:性能剖析和定期检测会有额外开销，但很有必要
5:New Relic好工具，会插入应用程序进行性能剖析，将收集到的数据发给一个基于Web的仪表盘，会测量很多用户体验的相关点，涵盖从Web浏览器到应用代码，再到数据库及其其他外部调用，好处是可以全天候测量生产环境的代码–即不限于测试环境，也不限于某个时间段

测量PHP应用程序
1:new relic
2:xhprof 开源，扩展性好，轻量级，可以在生产环境大量部署并全天候使用，针对函数调用进行剖析，并根据消耗时间进行排序
3:ifp 关注数据库调用，所以当无法在数据库层面进行测量的时候，ifp可以很好帮助应用剖析数据库的利用率
4:MySQL企业监控器，用户界面，可以直观显示查询剖析结果，并且可以根据时间段进行缩放

剖析MySQL查询

剖析服务器负载
1:服务器端可以有效的审计效率低下的查询
2:定位和优化“坏”查询可以显著提高性能，解决特定问题，降低服务器压力，这样所有的查询都将因为减少了对共享资源的争用而收益，降低服务器的负载还，推迟或者避免升级昂贵硬件
3:MySQL的每一个新版本都增加了更多的可测点
4:慢查询日志

捕获MySQL的查询到日志文件中
1:慢查询日志最初只是捕获比较“慢”的查询，而性能剖析需要针对所有查询，在MySQL版本5.1通过设置long_query_time为0来捕获所有查询，而且时间单位到微秒级
2:如果使用P ercona server，提供了对日志内容和查询捕获的更多控制能力
3:在MySQL，慢查询日志是开销最低、精度最高的测量查询时间的工具。对IO消耗忽略不计(CPU密集型场景影响稍微大一点),比较消耗磁盘空间，如果长期开启要部署日志轮转工具，不需要长期开起，只需要收集负载样本的期间开起即可
4:通用日志，很少用于分析和剖析服务器性能，在查询请求到服务器时进行记录，所以不包含响应时间和执行计划等重要信息。
5:5.1可以支持把日志记录到表，大部分情况没必要，会让慢查询到秒
6:P ercona serve的慢查询日志比MySQL记录更多的且有价值的信息，总的来说慢查询日志是一种轻量而且功能全面的性能剖析工具，是优化服务器查询的利器
7:权限不足，无法记录查询 P ercona tooklit的pt-query-digest中
–processlist不断查看show full processlist的输出
抓取TCP网络包，然后根据c/s协议进行解析

分析查询日志
1:教育利用慢查询日志捕获服务器查询，并且进行分析
2:不要直接断开慢查询日志进行分析，先生成一个剖析报告，如果需要则可以在看日志中需要特别关注的部分
3:pt-query-digest是分析MySQL查询日志最有力的工具
剖析单条查询
1:show profile，GA版本中包含真正查询剖析工具
2:MySQL的show status命令返回一些计数器
3:慢查询日志
4:performance schema还无法被当作一个通用的培训工具
使用性能剖析
1:获取服务器程查询剖析报告

诊断间接性问题
1:通过curl从一个运行的慢的外部服务获取汇率报价的数据
2:memcached缓存中的
一些重要条目过期，导致大量请求落到MySQL 以重新生成缓存条目
3:DNS查询偶尔超时现象
4:可能互斥锁争用，或者内部删除查询的算法效率太低的缘故，MySQL的查询缓存有时候会导致服务有短暂停顿
5:并发度超过某个阀值时，InnoDB 的扩展性限制导致查询计划的优化需要很长时间
单条查询问题还是服务器问题
1:show global status 比较高频率，一秒一次捕获数据，可以通过计数器的“尖刺”或者“凹陷”发现，简单且不需要权限，对服务器影响小
2:show processlist 观察是否有大量线程处于不正常状态或者其他不正常特征
3:查询日志， 需要开启慢查询日志并在全局级别设置0
理解发现问题
捕获诊断数据
1:诊断触发器，出现问题比较敏感，没有问题比较平稳
2:需要收集什么样的数据
3:解释结果数据

其他培训工具
1:user_statistics表。
可以查找使用最多或者使用最少的表索引，通过读取次数或者更新次数，或者两者一起排序
可以查找出从未使用的索引，可以考虑删除之
可以看看复制用户的connected_time和busy_time，以确认复制是否会很难跟上主库的进度
2:strace，可以调查系统调用情况