《高性能MySQL》 第二章 MySQL基准测试

benchmark是MySQL新手和专家需要掌握的基本技能。

2.1 为什么需要基准测试

• 验证基于系统的一些假设
• 重现系统中某些异常行为，解决异常
• 测试系统当前运行情况
• 模拟比当前系统更高的负载
• 测试应用适应可变环境能力。（随机并发峰值下额性能表现和不同配置的服务器之间的性能表现）

基准测试尽量简单直接，结果之间容易相互比较，成本低且容易执行。

2.2. 基准测试的策略

基准测试的策略主要由两种：意识针对整个系统整体测试，另外是单独测试MySQL。也就是集成式（full-stack）以及单组件式(single-component).

整体测试可以看清mysql是否为性能瓶颈，发现各部分之间的缓存带来影响，看清整个应用系统的性能。
不过有时只测试mysql是为了比较不同的schema或查询性能。

2.2.1 测试何种指标

将测试目标细化为一系列问题：这种CPU是否比另外一种快，新索引是否比当前索引更好。
有时候也要针对延迟和吞吐量采用不同的测试方法。

吞服量单位时间内事务处理数。针对在线事务处理的吞吐量，非常适用于多交互应用。TPS\TPM 每秒、每分钟
响应时间或延迟这个指标用于测试任务所需的整体时间。

并发性 并发性是一个非常重要又经常被误解和误用的指标。一个web站点可以有50000个用户访问，却只有10-15个并发请求发送到数据库，所以并发性测试需要关注的是正在工作中的并发操作或者是同时工作中的线程数或者连接数。要看在并发性激增的时候吞吐量是否下降，响应时间是否变长。

可扩展性大多数系统是无法做到理想的线性扩展的，随着压力的变化，吞吐量和性能都会越来越差。

2.3 基准测试方法

以下错误可能导致测试结果的无用或者不准确：

• 使用真实数据的子集而不是全集（数据之间的关联关系业务增加）
• 使用错误的数据分布，系统的真实数据有很多热点区域
• 使用不真实的分布参数，例如家底所有用户的个人信息都会被平均地读取
• 多用户场景中只做单用户测试
• 在单服务器上测试分布式应用
• 与真实用户行为不匹配（阅读翻页动作）
• 反复执行同一个查询。真实查询时不尽相同的，导致缓存命中率降低。
• 没有检查错误。
• 忽略了系统预热的过程。（预热时常）
• 使用默认的服务器配置。第三章讨论服务器优化配置。
• 测试时间太短了，基准测试需要持续一定时间。

2.3.1 设计和规划基准测试

专用测试规划–不同级别记录查询、参数和结果文档化规范。

2.3.2 基准测试应该运行多长时间

持续观察直到确认系统已经稳定。

2.3.3 获取系统性能和状态

执行基准测试时，尽可能多地手机被测试系统信息，最好简历一个目录。

需要记录：CPU使用率、磁盘IO、网络流量统计、SHOWGLOBAL STATUS计数器等等。

迭代式基于固定时间间隔的、每个文件分开有开始日期和结束日期（比在1GB文件上搜索要快）、不会处理或者过滤收集的数据（先收集再处理是好习惯）。测试完自动退出。

2.3.4 获得准确结果

每次测试要重启系统，经过系统预热时间也要记录。

2.3.5 运行基准测试结果并分析

自动化测试很重要，包括装载数据、系统预热、执行测试、记录结果。

2.3.6 绘图的重要性

2.4 基准测试工具

2.4.1 集成式测试工具

• ab 是一个apache http服务器基准测试工具。
• http_load web服务器进行测试，输入文件提供多个URL
• Jmeter java应用程序，加载其他应用并测试性能。

2.4.2 单件式测试工具

• mysqlslap 模拟服务器负载，并输出计时信息。
• mysql benchmark suite 在不同数据库服务器上进行比较测试单线程的，主要测试服务器执行查询速度。
• Super Smack 一款用于Mysql和PostgreSQL的基准测试工具，提供压力测试和负载生成。
• Database Test Suit
• Percona’s TPCC-MySQL TOOl
• sysbench

总结：看公司用什么以及身边小伙伴用什么，比较差异就好。

2.5 基准测试案例

2.6 总结