容我感慨一下：DBA真的不是盖的
3.3.3使用性能剖析：有本文来源gaodai#ma#com搞*!代#%^码$网!限
3.4诊断简歇性问题
如系统偶尔停顿、慢查询、唤影问题，尽量不要使用试错的方式解决问题：风险大
3.4.1单条查询问题还是服务问题
使用SHOW GLOBAL STATUS
较高频率：1s/次执行该命令铺获数据，问题出现通过计数器的
使用SHOW PROCESSLIST 【参考】显示哪些线程正在运行
使用查询日志
开启慢查询，设置全局的long_query_time=0,确认all连接采用了新设置（可能需要重置all连接使生效）
注意吞吐量突然下降时间段的日志，查询是在完成阶段才写入到慢查询日志的
好的工具事半功倍：tcpdump、pt-query-digest、Percona Server
理解发现的问题
可视化数据：gnuplot /R（绘图工具）
gnuplot：
安装 一些命令： 常用技巧 入门教程 2 Gnuplot 数据可视化
建议：先使用前两种方法，开销低且通简单shell脚本或反复执行的查询交互式收集数据
3.4.2铺获诊断数据
现间歇性问题，尽量多收集数据（不只是问题出现时的）
弄清楚：1、有区分 何时出现了问题 的方法：触发器；2、收集诊断数据的工具
诊断触发器
误差：在没有发生问题期间收集了很多诊断数据，浪费时间（这个和前的、仔细读一下 不矛盾）
漏检：在问题出现时没有铺获到数据，错失了机会，开始收集前确认触发器能够真正地识别问题
好的触发器：
找到些能和正常时的阈值进行比较的指标
选择一个合适的阈值：足够高（正常时不会触发）、不能太高（问题发生时不错过）
推荐工具pt-stalk【参考】【2】触发器，设定到某个条件记录 配置需监控的变量 阈值 检查的频率
收集什么样的数据
执行时间：工作的时间和等待的时间
在需要的时间段内收集all能收集的数据
未知问题发生的原因：1、服务器需做大量工作、导致大量消耗CPU；2、在等待资源释放
不同的方法收集诊断数据，确认原因：
1、剖析报告：确认是否有太多工作，工具：tcpdump 监听TCP流量 模式开闭慢查询日志
2、等待分析：确认是否存在大量等待，GDB堆栈跟踪信息、show processlist ，show innodb status观察线程、事务状态
解释结果数据
目的：1、问题是否真的发生了；2、是否有明显的跳跃性变化
工具：
oprofile利用cpu硬件层面提供的性能计数器(performance counter)，通过计数采样，帮助我们从进程、函数、代码层面找出占用cpu的"罪魁祸首"。实例【参考】
opreport命令，分别从进程和函数层面查看cpu使用情况的方法
samples | %|----------------------------------------------------- 镜像内发生的采样次数 采样次数所占总采样次数的百分比 镜像名称
opannotate命令可显示代码层面占用cpu的统计信息
GDB:Linux应用程序开发中，最常用的调试器是gdb(调试的对象是可执行文件)，它可以在程序中设置断点、查看变量值、一步一步跟踪程序的执行过程(数据、源码）、查看内存、堆栈信息。利用调试器的这些功能可以方便地找出程序中存在的非语法错误。【参考】【参考】 语法和实例
3.4.3一个诊断案例
转载请注明原文链接：【MySQL数据库】第三章解读：服务器性能剖析 （下）
