下面是一些零散的tips：
- 基准测试的一个主要问题是它不是完全真实的压力测试，真实的压力是不可预期并且变化多端的，有时候情况复杂而难以解释，不利于从结果中分析得出结论，因此基准测试施加的压力相比真实压力，要简单。
- 基准测试和真实情况最重要的不同是通常要求尽可能快地执行完成，所以经常会给系统造成过大压力。
- 通过测试工具可以控制施加到系统上的压力，但是很多工具并不能提供精确的控制，因此测试工具的局限性有时也会影响到结果的有效性
- 基准测试不能只根据测试结果做简单的推断。比如，对新老系统分别测试，发现新系统可支持的TPS(每秒事务数)是原系统的40倍，不能简单地下结论说新系统可以支持40倍的业务增长量，因为业务增长的同时，其他的东西也在改变，甚至应用本身的设计也会变化。基准测试只能适用于部分场景，对于估测新系统支持的业务增长量，可能还需要其他手段。
基准测试的策略
- 针对整个系统的整体测试 优点或理由：
- 用户关注整体的性能而非只是Mysql
- 往往应用的瓶颈并不在Mysql
- 只有整体测试，才能发现各部分相互之间缓存带来的影响
- 整体的测试才能体现出应用真实的表现，单个组件测试很难体现真实情况 缺点：
- 整体的基准测试很难建立，难度较高
- 针对Mysql数据库进行的单独测试 优点或理由：
- 需要比较不同的schema或查询的性能
- 针对应用中某个具体问题测试
- 为了避免漫长复杂的基准测试，单独测试可以做快速的短期的“周期循环”
测试指标
- 吞吐量 即单位时间内的事务处理数，如TPS(每秒事务数)、TPM(每分钟事务数)
- 响应时间或延迟 通常用百分比响应时间，即有95%的响应时间在5ms内，则表示任务在95%的时间段内都可以在5ms内完成
- 并发性 在任意时间有多少同时发生的并发请求或者在某同时工作的线程数下，吞吐量和延时的变化
- 可扩展性 给系统增加一倍的工作，理想情况下应当得获得两倍的结果(比如吞吐量)。或者增加一倍的资源(比如CPU数)，获得两倍的吞吐量。当然，大多数情况下是不可能线性增长的。
在读书的过程中发现本书过于高阶，主要专注于Mysql的性能优化，因此我们暂时先放一放，插播一些基础知识。 下一篇：Mysql基础知识汇总