MySQL进阶篇(01):基于多个维度,分析服务器性能

MySQL进阶篇(01):基于多个维度,分析服务器性能

一、服务器性能简介
1、性能定义
服务器性能优化是一项非常艰巨的任务,当然也是很难处理的问题,在写这篇文章的时候,特意请教下运维大佬,硬件工程师,数据库管理,单从自己的实际开发经验来看,看待这个问题的角度起码是不全面的。

补刀一句:在公司靠谱少撕逼,工程师这个体是很好交朋友的,互相学习一起进步,升职加薪他不好吗?

服务性能定义:完成一个任务或者处理一次接口请求所需要的时间,这个时间是指响应完成时间,即请求发出,到页面响应回显结束,这是看待性能问题的基本逻辑。

2、分析性能
服务的基本过程一般如下图,这是一张最简单的前后端分离,加一台数据库存储的流程,但是想要说明一个复杂的逻辑。

从页面请求,到获取完整的响应结果,这个过程每个环节都可能导致性能问题,抛开网络,硬件,服务器,MySQL存储这些核心客观因素,单是下面这行代码就可以秒掉很多人的努力。

Thread.sleep(10000); // 仿佛整个世界都安静了。
影响性能的因素很多,一般说性能优化会从下面几个方面考虑:

网络传输,比如私有云和公有云的交互,接口传输内容过大;
应用服务,接口设计是否最简,没有逻辑问题,架构设计是否合理;
存储服务,MySQL的查询写入,表设计是否合理,连接池配置是否合理;
硬件设施,CPU和内存的利用是否在合理区间,缓存是否合理;
这些问题每个处理起来都是非常耗费时间,且对人员的要求相对较高,不说一定要到达专家水平,起码性能问题出现时候,基本的意识要有。

二、MySQL执行机制
基于上述流程图,MySQL性能分析主要从下面几个方面切入,基本方向就不会偏。

1、连接池配置
查看默认最大连接数配置:

SHOW VARIABLES LIKE 'max_connections';
最小连接数是连接池一直保持的会话连接,这个值相对好处理许多,评估服务在正常状态下需要多少会话连接。

最大连接数服务器允许的最大连接数值,这个参数的设计就比较飘逸,需要对高并发业务有把控,且要分析SQL性能,和CPU利用率(基本上是70%-85%),想获得这一组参数,可是相当不容易,需要测试精细,配合运维进行服务监控记录,开发不断优化,可能要分库分表,或者集群,拆服务分布式化等一系列操作,最终才能得到合理处理逻辑,当然这样费心对待的都是核心业务,一般的业务也就是经验上把控。

2、SQL执行过程
MySQL解析器识别SQL的基本语法,生成语法树,然后优化器输出SQL可执行计划,非常复杂的流程。

客户端发送请求到MySQL服务器;
如果执行查询,会检查缓存是否命中;
服务端进行SQL解析,预处理,最后优化器生成执行计划;
根据执行计划调用存储引擎API执行;
返回客户端处理结果;
补刀一句:这也就是为什么现在接口提倡最简化设计,或者接口拆分,分步执行,不要问这样会不会多次请求,给网络造成压力,这都5G时代了。

3、逻辑总结
总结一句话:分析是否存在MySQL服务的性能问题,需要考量是不是服务配置问题,或者SQL编译过程问题,导致大量等待时间,还是SQL执行有问题,或者查询数据量过大导致执行过程漫长。

补刀一句:MySQL性能问题的基本原因很简单,数据量不断变大,服务器承载不住。作为开发,这是面对数据库优化的根本原因。

三、执行语句分析
1、基本描述
上面几个方面都是在说明面对服务性能问题时,意识上要清楚的边界,作为开发实际上要面对两个直接问题:表设计,SQL语句编写,大部分的开发都被这两个问题毒打过。

2、表结构设计
表设计:表设计关系到数据库的各个方面知识:数据类型选择,索引结构,编码,存储引擎等。是一个很大的命题,不过也遵循一个基本规范:三范式。

规范的表结构,合适的数据类型可以降低资源的占用,索引可以提高查询效率,存储引擎更是关系到事务方面的问题。

表的结构的逻辑清晰,是后续查询和写入的基本条件,结构过大,会出现很多索引,分表结构多,带来很多连接查询,同样会把开发感觉按在地上。这就涉及到一个玄学:开发要根据经验和因素,权衡表结构设计。

补刀一句:如果你去问3.5年的开发,最想写什么业务,他肯定会说单表的增删改查,为什么?因为这类任务是不会排期给他的。

3、数据更新
假设在表结构符合逻辑的情况下,数据更新(增删改)操作一般情况下不会出现较大问题,遵循几个基本原则。

数据量大的写入,执行批量操作,占用连接少;
删除和更新要考虑锁定的粒度,不要导致大范围锁定;
经常执行删除操作,要考虑内存碎片问题;
批量操作可以基于应用层面使用多线程处理;
4、数据查询
查询是开发中最常面对的问题,针对查询的规范也是特别多,确实查询也是最容易出错的环节。但是影响查询的因素很多,可能很多情况下查询只是背黑锅:

表设计规范,减少各种关联,子查询;
列类型规范,数据值规范,Null和空处理;
索引结构和使用规范,对查询性能影响最大;
存储引擎选择合适,直接影响锁定粒度大小;
外键关联导致表强行耦合,最讨厌的一个功能;
SQL在执行的时候,如果性能很差,还需要基于MySQL慢查询机制进行分析,查看是否出现磁盘IO,临时表,索引失效等各种问题。

四、模块总结
上述的描述可能感觉有点乱,但是整体上看,就分为下面三个模块

应用服务流程化分析,判断瓶颈出现环节;
熟悉MySQL基本机制,分析等待和执行时间;
MySQL的表结构设计和SQL执行优化;
这篇文章只是笼统描述一下服务性能的问题,重点还是想陈述一个基本逻辑:具备服务性能问题分析的意识,且意识的边界相对全面,不要只盯着某个方面思考。

补刀一句:因为文章的分类是MySQL模块,所以重点的描述也在MySQL层面。实际情况中,任何层面都可能导致性能问题。

五、源代码地址
GitHub·地址
https://github.com/cicadasmile/mysql-data-base
GitEE·地址
https://gitee.com/cicadasmile/mysql-data-base
本文源码:GitHub·点这里 || GitEE·点这里
原文地址https://www.cnblogs.com/cicada-smile/p/12637476.html