玩转MySQL：调优后的单机数据库在高并发下起飞

最新推荐文章于 2024-07-29 03:53:57 发布

Java_LingFeng

最新推荐文章于 2024-07-29 03:53:57 发布

阅读量707

点赞数

文章标签：数据库 sql mysql 程序人生 java

本文链接：https://blog.csdn.net/Java_LingFeng/article/details/127980824

版权

引言

在当前的IT开发行业中，系统访问量日涨、并发暴增、线上瓶颈等各种性能问题纷涌而至，性能优化成为了现时代中一个炙手可热的名词，无论是在开发、面试过程中，性能优化都是一个常谈常新的话题。而MySQL作为整个系统的后方大本营，由于是基于磁盘的原因，性能瓶颈往往也会随着流量增大而凸显出来。

但在一个业务系统中，性能优化其实可以从多个角度出发考虑，如架构优化、前端调优、中间件调优、网关调优、容器调优、JVM调优、接口调优、服务器调优、数据库调优.... 等，从优化类型上而言，主体可以分为三类：

①结构/架构优化：优化应用系统整体架构做到性能提升的目的。如：读写分离、集群热备、分布式架构、引入缓存/消息/搜索中间件、分库分表、中台架构（大数据中台、基础设施中台）等。
②配置/参数优化：调整应用系统中各层面的配置文件、启动参数达到优化性能的目标。如：JVM、服务器、数据库、操作系统、中间件、容器、网关参数调整等。
③代码/操作优化：开发者编写程序时，从代码、操作方面进行调节，达到效率更高的初衷。如：代码中使用更优秀的算法思想/设计模式、SQL优化、对中间件的操作优化等。

本章则重点讲述MySQL的性能优化策略，一般MySQL都是整个业务系统中，调优选项的重中之重，毕竟MySQL作为系统大本营，当它出现瓶颈时，会影响整个系统其他节点的运行，比如：当MySQL出现了性能瓶颈时，就算Java程序没出现瓶颈，也会因此受到限制，这也是著名的木桶效应：一个木桶能装多少水，完全取决于木桶中最短的那块木板。

一、系统中性能优化的核心思维

性能调优与线上排查问题一样，是建立在经验的基础之上才能做好的，对于调优要实事求是，任何的调优手段或技巧不要纸上谈兵，只有经过实践的才能用于生产环境，千万不要将一些没有实际依据的调优策略用于线上环境，否则可能会导致原本好好运行的应用程序，反而由于调优被调到崩溃。

1.1、单个节点层面调优的核心思想

在一个程序中，所有的业务执行实体都为线程，应用程序的性能跟线程是直接挂钩的。而程序中的一条线程必须要经过CPU的调度才可执行，线程执行时必然也会需要数据、产生数据，最终也会和内存、磁盘打交道。因而单个节点的性能表现，不可避免的会跟CPU、内存、磁盘沾上关系。线程越多，需要的CPU调度能力也就越强，需要的内存也越大，磁盘IO速率也会要求越快。因此CPU、内存、磁盘，这三者之间的任意之一达到了瓶颈，程序中的线程数量也会达到极限。达到极限后，系统的性能会成抛物线式下滑，从而可能导致系统整体性能下降乃至瘫痪。

由于如上原因，在考虑性能优化时，必然不能让CPU、内存、磁盘等资源的使用率达到95%+，一般而言，最大利用率控制在80-85%左右的最佳状态。

同时，由于程序的性能跟线程挂钩，所以线程工作模型也是影响性能的重要因素。目前程序设计中主要存在三种线程处理模型：BIO、NIO、AIO（NIO2），BIO是最传统的一对一处理模型，也就是一个客户端请求分配一条线程处理。NIO的最佳实践为reactor模型，而proactor模型又作为了NIO2/AIO的落地者。绝大部分情况下，AIO的性能优于NIO，而NIO的性能又远超于BIO。

所以在做性能优化时，你应该要清楚系统的性能瓶颈在哪儿，到底是要调哪个位置？是线程模型？或是CPU调度？还是内存回收？亦是磁盘IO速率？针对不同层面有不同的优化方案，并非为了追求“热词/潮流”而盲目的调优。

1.2、优秀且适用的系统架构胜过千万次调优

一个单体架构（Tomcat+MySQL）部署的系统遇到性能问题时，能力再强，本事再大，任凭使出浑身解数也无法将其调到处理万级并发的程序，正常服务器部署的一台MySQL服务做到极致调优也难以在一秒内承载5000+的QPS。一味地追求极致的优化，其实也难以解决真正大流量下的并发冲击，因此一套优秀的系统架构胜过自己千万次的调优。

当然，也并非说项目实现时，越多的技术加进来越好，一套完善的分布式架构就必然比单体架构要好吗？其实也不见得，因为当引入的技术越多，所需要考虑的问题也会更多，耗费的成本也会越高，一个项目收益60W，结果用上最好的配置（高端的开发者+顶级的服务器+完善的分布式架构）成本耗费200W，这值得吗？答案显而易见。因此，并没有最好的技术架构，只有最适用的架构，能从现有环境及实际业务出发，选用最为合适的技术体系，这才是我们应该做的事情。如：

项目业务中读写参半，单节点难以承载压力，项目集群、双主热备值得参考。
项目业务中写大于读，引入消息中间件、DB分库、项目集群也可以考虑。
项目业务中读大于写，引入缓存/搜索中间件、动静分离、读写分离是些不错的选择。
.......

当你的系统原有架构遇到性能瓶颈时，你甚至可以考虑进一步做架构优化，如：设计多级分布式缓存、缓存中间件做集群、消息中间件做集群、Java程序做集群、数据库做分库分表、搜索中间件做集群.....，慢慢的，你的系统会越来越庞大复杂，需要处理的问题也更为棘手，但带来的效果也显而易见，随着系统的结构不断变化，承载百万级、千万级、亿级、乃至更大级别的流量也并非难事。

但只有当你的业务流量/访问压力在选用其他架构无法承载时，你才应该考虑更为庞大的架构。当然，如果项目在起步初期就有预估会承载巨大的流量压力，那么提前考虑也很在理，采用分布式/微服务架构也并非失策，因为对比其他架构体系而言，微服务架构的拓展性更为灵活。但也需要记住：分布式/微服务体系是很好，但它不一定适用于你的项目。

1.3、预防大于一切，调优并非“临时抱佛脚”

当问题出现时再想办法解决，这种策略永远都属于下下策，防范于未然才是最佳方案，提前防范问题出现主要可分为两个阶段：

①项目初期预测未来的流量压力，提前根据业务设计出合适的架构，确保上线后可以承载业务的正常增长。
②项目上线后，配备完善的监控系统，在性能瓶颈来临前设好警报线，确保能够在真正的性能瓶颈到来之前解决问题。

对于项目初期的架构思考，值得牢记的一点是：不要“卡点”设计，也不能过度设计造成性能过剩，举例：

项目上线后的正常情况下，流量大概在“一木桶”左右，结果你设计时直接整出一个承载“池塘”级别的流量结构，这显然是不合理的，毕竟架构体系越庞大，项目的成本也自然就越高。当然，也不能说正常情况下压力在“一木桶”左右，就只设计出一套仅能够承载“一木桶”流量的结构，这种“卡点”设计的策略也不可取，因为你需要适当考虑业务增长带来的风险，如果“卡点”设计，那么很容易让项目上线后，短期内就遭遇性能瓶颈。因此，如果项目正常的访问压力大概在“桶”级别，那将结构设计到“缸”级别最合理，这样即不必担心过度设计带来的性能过剩，导致成本增高，也无需考虑卡点设计造成的：项目短期遭遇性能瓶颈。但设计时的这个度，必须由你自己根据项目的业务场景和环境去思量，不存在千篇一律的方法可教。

有人曾说过：“如果你可以根据业务情景设计出一套能确保业务增长，且在线上能稳定运行三年时间以上的结构，那你就是位业内的顶尖架构”，但老话说的好：“计划永远赶不上变化”，就算思考到业务的每个细节，也不可能设计出一套一劳永逸的结构出现，我们永远无法判断意外和明天哪个先来。因而，项目上线后，配备完善的监控警报系统也是必不可少的。不过值得注意的是：

监控系统的作用并不是用来提醒你项目“嗝屁”了的，而是用来提醒你：线上部署的应用系统可能会“嗝屁”或快“嗝屁”了，毕竟当项目灾难已经发生时再给警报，那到时候的情况就是：“亡羊补牢，为时已晚”。通常情况下，在监控系统上面设置的性能阈值都会比最大极限值要低5~15%，如：最大极限值是85%，那设置告警值一般是75%左右就会告警，不会真达到85%才告警，只有这样做才能留有足够的时间让运维和开发人员介入排查。当系统发出可能“嗝屁”的警告时，开发和运维人员就应当立即排查相关的故障隐患，然后再通过不断地修改和优化，提前将可能会出现的性能瓶颈解决，这才是性能调优的正确方案。因此，最终结论为：绝不能等到系统奔溃才去优化，预防胜于一切。