这篇文章给大家介绍MySQL中如何理解基于多个维度分析服务器性能,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。
创新互联建站是一家集网站建设,靖江企业网站建设,靖江品牌网站建设,网站定制,靖江网站建设报价,网络营销,网络优化,靖江网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
服务器性能优化是一项非常艰巨的任务,当然也是很难处理的问题,在写这篇文章的时候,特意请教下运维大佬,硬件工程师,数据库管理,单从自己的实际开发经验来看,看待这个问题的角度起码是不全面的。
补刀一句
:在公司靠谱少撕逼,工程师这个群体是很好交朋友的,互相学习一起进步,升职加薪他不好吗?
服务性能定义:完成一个任务或者处理一次接口请求所需要的时间,这个时间是指响应完成时间,即请求发出,到页面响应回显结束,这是看待性能问题的基本逻辑。
服务的基本过程一般如下图,这是一张最简单的前后端分离,加一台数据库存储的流程,但是想要说明一个复杂的逻辑。
从页面请求,到获取完整的响应结果,这个过程每个环节都可能导致性能问题,抛开网络,硬件,服务器,MySQL存储这些核心客观因素,单是下面这行代码就可以秒掉很多人的努力。
Thread.sleep(10000); // 仿佛整个世界都安静了。
影响性能的因素很多,一般说性能优化会从下面几个方面考虑:
网络传输,比如私有云和公有云的交互,接口传输内容过大;
应用服务,接口设计是否最简,没有逻辑问题,架构设计是否合理;
存储服务,MySQL的查询写入,表设计是否合理,连接池配置是否合理;
硬件设施,CPU和内存的利用是否在合理区间,缓存是否合理;
这些问题每个处理起来都是非常耗费时间,且对人员的要求相对较高,不说一定要到达专家水平,起码性能问题出现时候,基本的意识要有。
基于上述流程图,MySQL性能分析主要从下面几个方面切入,基本方向就不会偏。
查看默认最大连接数配置:
SHOW VARIABLES LIKE 'max_connections';
最小连接数是连接池一直保持的会话连接,这个值相对好处理许多,评估服务在正常状态下需要多少会话连接。
最大连接数服务器允许的最大连接数值,这个参数的设计就比较飘逸,需要对高并发业务有把控,且要分析SQL性能,和CPU利用率(基本上是70%-85%),想获得这一组参数,可是相当不容易,需要测试精细,配合运维进行服务监控记录,开发不断优化,可能要分库分表,或者集群,拆服务分布式化等一系列操作,最终才能得到合理处理逻辑,当然这样费心对待的都是核心业务,一般的业务也就是经验上把控。
MySQL解析器识别SQL的基本语法,生成语法树,然后优化器输出SQL可执行计划,非常复杂的流程。
客户端发送请求到MySQL服务器;
如果执行查询,会检查缓存是否命中;
服务端进行SQL解析,预处理,最后优化器生成执行计划;
根据执行计划调用存储引擎API执行;
返回客户端处理结果;
补刀一句
:这也就是为什么现在接口提倡最简化设计,或者接口拆分,分步执行,不要问这样会不会多次请求,给网络造成压力,这都5G时代了。
总结一句话:分析是否存在MySQL服务的性能问题,需要考量是不是服务配置问题,或者SQL编译过程问题,导致大量等待时间,还是SQL执行有问题,或者查询数据量过大导致执行过程漫长。
补刀一句
:MySQL性能问题的基本原因很简单,数据量不断变大,服务器承载不住。作为开发,这是面对数据库优化的根本原因。
上面几个方面都是在说明面对服务性能问题时,意识上要清楚的边界,作为开发实际上要面对两个直接问题:表设计,SQL语句编写,大部分的开发都被这两个问题毒打过。
表设计:表设计关系到数据库的各个方面知识:数据类型选择,索引结构,编码,存储引擎等。是一个很大的命题,不过也遵循一个基本规范:三范式。
规范的表结构,合适的数据类型可以降低资源的占用,索引可以提高查询效率,存储引擎更是关系到事务方面的问题。
表的结构的逻辑清晰,是后续查询和写入的基本条件,结构过大,会出现很多索引,分表结构多,带来很多连接查询,同样会把开发感觉按在地上。这就涉及到一个玄学:开发要根据经验和因素,权衡表结构设计。
补刀一句
:如果你去问3.5年的开发,最想写什么业务,他肯定会说单表的增删改查,为什么?因为这类任务是不会排期给他的。
假设在表结构符合逻辑的情况下,数据更新(增删改)操作一般情况下不会出现较大问题,遵循几个基本原则。
数据量大的写入,执行批量操作,占用连接少;
删除和更新要考虑锁定的粒度,不要导致大范围锁定;
经常执行删除操作,要考虑内存碎片问题;
批量操作可以基于应用层面使用多线程处理;
查询是开发中最常面对的问题,针对查询的规范也是特别多,确实查询也是最容易出错的环节。但是影响查询的因素很多,可能很多情况下查询只是背黑锅:
表设计规范,减少各种关联,子查询;
列类型规范,数据值规范,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
推荐阅读:
MySQL数据库基础
序号 | 文章标题 |
---|---|
01 | MySQL基础:经典实用查询案例,总结整理 |
02 | MySQL基础:从五个维度出发,审视表结构设计 |
03 | MySQL基础:系统和自定义函数总结,触发器使用详解 |
04 | MySQL基础:存储过程和视图,用法和特性详解 |
05 | MySQL基础:逻辑架构图解和InnoDB存储引擎详解 |
06 | MySQL基础:事务管理,锁机制案例详解 |
07 | MySQL基础:用户和权限管理,日志体系简介 |
关于MySQL中如何理解基于多个维度分析服务器性能就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
售后响应及时
7×24小时客服热线数据备份
更安全、更高效、更稳定价格公道精准
项目经理精准报价不弄虚作假合作无风险
重合同讲信誉,无效全额退款