引言
近期打算对mysql的性能优化做一个整理，有小伙伴说各大论坛mysql性能优化文章多了去了，深浅不一，为什么还要自己再花时间写一遍？我认为要想真正地掌握一些知识，还是要自己去梳理，整理，实践，缺一不可。查阅只能达到临时记忆，毕竟不是自己的东西。一个多月之前写的一篇JVM-GC全解也会经常回顾，有些也忘记了。自己写的都是如此，更何况临时查找的东西。
作为现今使用最广泛的数据库之一，不管是架构，开发，测试，运维都能对mysql的性能调优说上几句。最简单的无非是，建立高效索引以提高sql执行速度，再不行就扩容机器配置，要不就调一些对性能影响较大的参数。我们在实际的性能测试中大部分也是这么做的，但是很多人知其然不知其所以然，为什么这样做会提高性能，不能了然于胸。也许只知道这些足够一个软件性能测试人员用的了，但是我还是想往深挖一点，可能在性能测试中养成了强迫症，一个问题一定要瓦根刨地的解决掉，要不然心里总是有个疙瘩解不开，很不舒服。
本次mysql系列文章多以性能定位及优化的角度来整理，包括了性能优化思路剖析、mysql体系架构、InnoDb存储引擎、索引、sql查询、服务器/硬件优化等方面，暂不会涉及到可扩展性和高可用性之类的知识点，毕竟不是专业的DBA，以后有时间可以再学习整理。
性能优化思路剖析
CPU层面
一开始接触性能优化的时候，认为数据库层面性能优化就是减少sql执行时间，降低CPU利用率，减少对资源的使用。但这是一个误区，资源就是用来消耗并用来工作的，有时更多的消耗可以加快查询速度，降低响应时间。合理的使用资源的前提下，高CPU消耗并不能说明有性能问题，反而说明了对资源高效的利用。例如在切换InnoDb存储引擎或者使用高性能索引的时候，就会出现这种现象。当然，没有索引的查询或者低效索引也会引起高CPU的现象。所以说CPU利用率只是一种现象，而不是很好的可度量的目标。
QPS及响应时间
每秒的查询量，也可以称之为吞吐量。对查询的优化可以使得服务器在相同时间内执行更多的查询。所以如果你的目标是降低响应时间，那就需要了解sql执行的生命周期，为什么服务器查询需要这么多时间，然后再去减少对查询结果来说不必要的工作。
测试与调优的思考
我们在做测试的过程中，经常会进入一个误区，将精力放到优化，而不是通过压测去精准的发现问题。如果通过测试没有找到问题，那要么是测试的方向错了，要么是测试的范围不够完整。对症下药才能更高效精准的解决问题，降低开发人员和测试人员的成本。所以说测出时间花费在了哪里，和知道为什么花在哪里，完全是两码事情。
这就引发了另外一个问题：测试的精准度（扩展一下，突然想到了）
因为测试环境和生产环境的差异包括：服务器自身性能，程序包的不同，网络及网络设备，数据准备性及数据量等，多多少少都会引起测试结果的不准确性。所以近几年，全链路压测被频繁提起，很多大厂像BAT及部分金融IT企业已经实现了线上压测。全链路压测也是检验一个企业IT实力的一个硬性的指标。因为线上全链路压测不仅仅是测试人员的事情，它包括了对中间件的改造（测试流量标记及熔断机制），脏数据处理（影子表概念），对线上生产环境的监控以及对业务影响的准确评估等等，有机会后面专门写一篇全链路压测的文章，详细讲解一下。
定位问题之后的优化思考
是否值得优化
通过一些工具定位到问题之后，可以着手进行调优，但是工具并不会告诉你哪些问题值得去优化。如果一些低频业务有效率问题，虽然通过人力投入优化了问题，但并不会是业务收入有任何增加，那这种优化是没有必要的，反而是优化成本大于收益。
高频业务的性能极致
对于高频业务，即时生产上目前没有问题，也要通过测试，找到对应的高频sql，对其进行极致的优化。主要基于两个考虑：一个是以面对突如其来的业务压力，保证业务的正常运行；二是高频时sql必然会引起响应时间的增加，响应时间长了又反过来业务产生影响，例如用户接收不到返回就会一直刷新，使得数据库压力成本增加，很容易引发生产问题。
要相信平均数吗
平均数会展示很多信息，同样也会隐藏掉很多信息，没办法展示出全貌。例如在JVM的GC中，FULL GC平均是1s，但是有一次FULL GC长达10s，那对于在这10s中的用户体验是非常糟糕的。Mysql也是同样的道理。
最有效的方式
通常情况下，提升硬件能力可以直线拉升mysql的处理能力，也是最有效的方式。一是扩大服务器的CPU及内存，二是更换性能更好地存储介质（SSD）。
期待
关于性能优化思路剖析先分享那么多，后面想到其他的再补充上来，接下来就从性能的角度，全方位的窥探下mysql，未完待续。
欢迎阅读点赞其他系列文章，给我分享知识的热情添把火：
