年少不知优化苦，遇坑方知优化难。——村口王大爷
全文内容预览：
我之前有很多文章都在讲性能优化的问题，比如下面这些：
- 《switch 的性能提升了 3 倍，我只用了这一招！》
- 《String性能提升10倍的几个方法！(源码+原理分析)》
- 《局部变量竟然比全局变量快 5 倍？》
- 《池化技术到达有多牛？看了线程和线程池的对比吓我一跳！》
- 《链表竟然比数组慢了1000多倍？(动图+性能评测)》
- 《HashMap 的 7 种遍历方式与性能分析！》
- 更多性能优化文章
当然，本篇也是关于性能优化的，那性能优化就应该一把梭子吗？还是要符合一些规范和原则呢？
所以，在开始之前（MySQL 优化），咱们先来聊聊性能优化的一些原则。
性能优化原则和分类
性能优化一般可以分为：
- 主动优化
- 被动优化
所谓的主动优化是指不需要外力的推动而自发进行的一种行为，比如当服务没有明显的卡顿、宕机或者硬件指标异常的情况下，自我出发去优化的行为，就可以称之为主动优化。
而被动优化刚好与主动优化相反，它是指在发现了服务器卡顿、服务异常或者物理指标异常的情况下，才去优化的这种行为。
性能优化原则
无论是主动优化还是被动优化都要符合以下性能优化的原则：
- 优化不能改变服务运行的逻辑，要保证服务的正确性；
- 优化的过程和结果都要保证服务的安全性；
- 要保证服务的稳定性，不能为了追求性能牺牲程序的稳定性。比如不能为了提高 Redis 的运行速度，而关闭持久化的功能，因为这样在 Redis 服务器重启或者掉电之后会丢失存储的数据。
以上原则看似都是些废话，但却给了我们一个启发，那就是我们性能优化手段应该是：预防性能问题为主+被动优化为辅。
也就是说，我们应该以预防性能问题为主，在开发阶段尽可能的规避性能问题，而在正常情况下，应尽量避免主动优化，以防止未知的风险（除非是为了 KPI，或者是闲的没事），尤其对生产环境而言更是如此，最后才是考虑被动优化。
PS：当遇到性能缓慢下降、或硬件指标缓慢增加的情况，如今天内存的占用率是 50%，明天是 70%，后天是 90% ，并且丝毫没有收回的迹象时，我们应该提早发现并处理此类问题（这种情况也属于被动优化的一种）。
