前言
接续上文继续介绍：《高性能Mysql》学习笔记（一）。
mysql 时间线
基准测试
为什么需要基准测试
基准测试策略
- 基于mysql 单独测试 - 单组件式
- 对整个系统整体测试 - 集成式
使用整个系统测试原因主要如下
如果不需要关注整体应用，只关注msyql 性能
测试指标
- 吞吐量
- 响应时间或者延迟
- 并发性
- 可扩展性
应当避免以下情况再进行基准测试
获取系统性能和状态
获取基准测试结果
运行基准测试并分析结果
使用 shell , php, perl 都可以实现
结果分析图表
gnuplot > plot "qps-per-5-seconds" using 5 w lines title "qps"
基准测试工具
- apach AB
- http_load
- jmeter
单组件式测试工具
- mysqlslap
- 包含在mysql5.1 的发行包当中，会自动生成查询schema的select 语句
- mysql benchmark suite (sql-bench)
- 优点：单线程，测试服务器执行查询的速度。
- 有大量预定义的测试
- 缺点：单用户模式，测试数据集很小而且无法指定数据
- 无法测试多cpu能力
- super mack
- 用于 mysql 和 postgresql 基准测试工具
- database test suite
- 类似工业标准的测试工具
- dbt2 免费的toc-c oltp 测试工具
- percona's tpcc-mysql tool
- mysql 高性能并发作者自己制作
- sysbench
- 多线程系统压测工具
- 支持lua 语言
msyql 的 benchmark() 函数
Mysql 内置，可以测试某些特定操作的执行速度
方便的测试某些特定操作性能，比如md5() 比 sha1() 函数快
基准测试案例：
重点熟悉 sysbench 测试 ，因为和mysql 自身的设计最为贴合
服务器性能剖析
性能优化简介
一句话概括：性能即响应时间
原则
- 一定的工作负载之下尽可能的降低响应时间
- 无法测量就无法有效优化
忌讳
- 错误的时间启动和停止测量
- 测量的是聚合后的信息，而不是目标活动本身
完成一项任务可以分成两部分
- 执行时间：优化通过测量定位不同的子任务花费的时间，优化一些子任务，降低子任务的执行效率或者提升
- 等待时间
如何判断测量是正确的？
测量到底有多么不准确，记住一点，使用的测量数据而不是实际数据，测量数据也有多种表现。很容易推导出错误的结论
性能剖析进行优化
任务结束时间减去启动时间得到响应时间
性能剖析两种类型
- 基于时间分析
- 某时候执行时间就是在等待
- 比如i/o或者查询等待时间过久
- 基于等待分析
理解性能剖析
将最重要的任务展示在前面，但是没有显示的信息也很重要
值得优化的查询：
- 一些只占总响应时间比重很小的查询不值得优化
- 如果优化成本大于收益，要停止优化！
异常情况：
某些任务没有性能剖析输出也要优化，比如某些任务执行次数很少，但每次都很慢
未知的未知
好的剖析工具尽可能显示“丢失的时间”
丢失的时间： 任务的总时间和实际测量时间时间的差
被掩藏的细节：
平均值不能完全相信和作为根据
应用程序的性能剖析：
对于任何需要消耗时间的任务都可以进行性能分析
实用软件： New Relic
捕获查询到日志文件当中
- mysql 5.0 之前， 慢查询日志的响应时间是秒
- mysql 5.1 之后，慢查询被加强，可以做到微秒级别的查询
慢查询日志是进度最高测量查询的日志，开销几乎可以忽略不计，但是会消耗大量磁盘空间，
percona server 慢查询日志
- 通过--processlist 选项不断查看 show full processlist 的输出
- 通过抓取 tcp 网络包，根据mysql 客户端 /服务端 通信协议进行剖析
建议： 在服务器上使用慢查询日志捕获所有的查询
应该首先生成一个剖析报告，在进行慢查询
剖析报告
剖析单条查询
1. 使用 show profile
mysql 5.1 之后版本引入，默认是禁用的，但是可以通过服务器变量在连接中动态更改mysql> set profiling = 1
开启后会测量查询执行相关操作的状态
可能被 performance scheema 取代
该工具会讲剖析信息做成一张临时表
示例
- 执行下列语句
- 返回997行数据
- 继续看待下面输出
- 如果不使用上面方法，则使用下列方法
2. 使用 show status
该命令返回了一些计数器，既有 服务器界别全局计数器，也有基于某个连接的会话级别计数器，show global status 可以查询服务器启动时候开计算查询次数的统计
全局计数器也会出现在show status
猜测操作代价或者消耗时间较多的，可以使用句柄计数器， 临时文件和表计算器
示例
3. 使用慢查询日志（重点）
通过 pt_query_digest 发现“坏查询”
# query 1 :0 ops, 0x concurrency, ID oxeexxxs at byte 3214 ___
使用下面方法查看详情
tail -c +3214 /path/to/query.log | head -n100
4. 使用performance Schema
mysql 5.5 之后新增还不支持查询级别的剖析信息
下面是显示系统等待主要原因的查询：
