最近运气好到爆，平均一个月一次感冒不说，看的书也越来越不错。

最近在恶补高性能mysql一书，以小白姿势强烈推荐！

关于性能测试的误区，感同身受。

1. 错误使用数据分布，例如使用均匀分布的的数据测试，而系统真实的数据有很多热点区域(随机生成的数据反而无法模拟真实数据分布)；

2. 多用户场景，只用单用户做测试；

3. 在单服务器上测试分布式应用；

4. 与真实用户行为不匹配；例如web页面会有思考时间，也就是真实用户请求一个页面后会阅读一段时间，而不是不停定的一个接一个链接的点击；

5. 反复执行同一个查询，这样会全部或者部分缓存结果；

6. 没有检查错误日志，比如一个本应该很慢的查询突然变快，那就要去查看是否有错误产生。否则可能只是测试了系统检测到错误的速度。测试完成，一定要检查错误原因；

7. 忽略了系统预热的过程，预热过的系统和系统重启后(冷)马上进行测试是不一样的结果。

8. 使用默认的服务器，应考虑服务器优化。

9. 性能测试时间太短；参见7.

看完站起来做做运动…

周末愉快

今日份

1. 基于mysql的默认配置的测试没有任何意义，因为默认配置是基于消耗很少内存的极小应用的。

2. 绘图的重要性，尽早使用绘图方式，熟练gnuplot或者R这样的绘图工具，来发现一些隐藏的性能尖刺。

3. sysbench可以执行多种类型的基准测试，不仅设计用来测试数据库的性能，也可以测试运行数据库的服务器的性能。sysbench的cpu基准测试，比较cpu的性能；sysybench的文件IO基准测试，如果文件中的数据能完全放入内存中，则操作系统缓存大部分的数据，导致测试结果无法体现IO密集型的工作负载；sysbench的OLTP基准测试，模拟事务处理系统的工作负载；

4. 测量服务器的时间花费在哪里，使用的技术则是性能剖析(profiling). 测出时间花在哪里。

5. 完成一项任务的时间=执行时间+等待时间。

6. 对系统性能剖析建议自上而下的进行，应用层—>数据库，性能瓶颈可能因素：需要处理大量的数据，在循环中执行昂贵的操作，例如滥用正则表达式，使用了低效的算法，比如使用暴力搜索算法；

7. 诊断mysql的问题时候，首先考虑使用SHOW STATUS和SHOW PROCESSLIST，开销很低；或者开启mysql的慢查询日志，慢查询的开销可以忽略不计，但是要考虑磁盘的大量消耗，可以在负载测试期间开启即可。分析慢查询日志要相对困难一些。

8. 推荐使用pt-query-digest工具来分析慢查询的日志，而不是直接打开慢查询日志进行分析。pt-query-digest会将查询的剖析报告打印出来，并把“重要”的查询逐条打印出来。

图片这段冷酷无情的描述，却是我心动的感觉。

糟了，是心动的感觉