ARTS - Share 补2019.1.2

提高系统性能方式的总结

问题提出

根据最近一列的优化系统性能，形成了一点思考，做下总结。

所谓提高系统性能，就是把慢的地方，变成快的地方。哪个地方容易慢？磁盘、网络IO、计算密集操作，这些就对应着数据库优化，网络请求，和各类计算。那么，对应的解决方案就是减少磁盘操作，如优化数据库索引，换成内存操作，如使用缓存，如进行预处理。

加缓存

因为内存操作远快于磁盘操作，所以对于有些查询类且不经常变化的数据例如用户信息类、历史统计表等放入缓存，下次直接读取缓存，提高的性能就相当于内存相对磁盘的性能。

加缓存要注意的事项是，这些数据确实变动小，这样缓存命中率高，很少穿透。同时选择好缓存失效策略。

另外注意事项是，缓存作为一种提高系统性能的工具，是系统辅助部分，并不能把核心数据只存进缓存，持久化操作还是必须要有的。

优化MySQL

当数据量达到百万级别时，数据库的查询优化就变成了很重要的一件事，特别是在各种连接和分组函数共同使用情况。

几个关键字是 慢查询日志、explain 、索引、processlist.

平时打开慢查询日志，找出查询缓慢的SQL，使用执行计划explain, 判断索引情况，调整索引策略。 使用show processlist 查看当前正在执行的语句，当系统拥挤时候，可以看到是哪些语句正在堵塞，然后有计划的优化这些语句，或调整连接池大小等。

预处理

预处理方式就是把一下因计算量大而影响响应时间且非实时性的功能，挪到空闲时间计算，用到直接取。

例如系统要获得前一天人员工作效率情况，那么这些查询工作可以在第二天凌晨进行跑各种批量与聚合数据，然后在使用时候直接就能获取到结果，不必实时计算。

梳理业务实现

面对这些系统问题，不能只使用程序员的技术手段，同时要根据业务情况，考虑是否自己实现方式出现了问题。比如要做个每日用户数统计，当天的不算，可以选择每天跑批计算存储当天的用户数， 也可以实时统计过滤掉当天的用户，明显第二种更方便简洁，所以有时候多想想自己真正需要的东西，和业务需求背后隐藏的真实需求，这样设计出的系统更能从人为角度避开性能问题。

总结

总之，当系统出现响应慢时候，要首先去定位问题，不要上来就直接加缓存。当然时间紧急情况下当然可以，只是这是个治标不治本的方案。在时间够的情况下，我们要主动分析到底哪里是真正的瓶颈。比如本人最近遇到的一个报表查询问题， 数据量百万级别，首先定位问题是由于联合索引最左匹配原则没匹配好，导致了全表扫描，因此系统巨慢，最后建好索引，速度顿时飞起。但是偶尔还会报这个查询慢，明明已经在数据库测试查询很快了，查看show processlist ，有大量语句堆积，然后检查了连接池设置，发现最大设置为20个，明显对于几百人使用的系统，完全不够用，最后调大后，问题解决，最后由于查询数据并非经常变动， 加了缓存后，速度更是飞起。

最后，根据二八原则， 当系统变的巨慢，大部分是数据库索引问题，再加缓存，基本解决8成的问题， 剩下的两成就需要经验与耐心，去寻找真正的瓶颈了。