「轻阅读」Mysql调优你不得不知的细节

喜欢吃鱼的青年 2019-12-09 17:55:47 ⋅ 375 阅读
原文地址:https://www.toutiao.com/i6600157332582171150

调优的目的

多数时候数据库会成为整个系统的瓶颈,比如大的数据量的插入与修改,频繁的亦或是高流量的访问,都会对数据库系统带来很大的压力。以下是小编工作时总结的经验,提供给大家,仅供参考。

调优的手段

1、缓存。缓存是解决这类问题的一把手。它既可以加快整个系统(并非数据库系统,使用缓存的时候并没有去访问数据库)的访问速度,也可以减少数据库负载的压力。而缓存一般都是在查询中使用,我们并不希望每一次的查询都要去访问数据库。那么我们的缓存做到哪里呢?一般情况下版的系统都会存在服务层这一结构层次,而数据访问层一般都只是对于数据库的增删改查的接口的定义,所以我们的缓存就需要在服务层进行。而mybatis中的一级缓存,通过判断查询条件是否要访问数据库,查询条件与某一次相同,则直接返回缓存中的数据,查询条件不同则需要访问数据库,并且将结果放到缓存中。

2、当只需要一条数据时使用LIMIT 1.我们作为开发者,是能够知道我们需要的数据的条数的,若已经知道结果只有一条的时候,一定要使用limit 1 ,这样一来,MySQL在查询到一条数据之后,会立即停止搜索,这会带来性能上的提升。

3、避免select * ,取之所需。公司里的一些同事,无论查询什么都是直接select *,然后再从结果中取想要的字段。这样做的话,平白无故的给MySQL带来了不必要的负担,因为从数据库中读出越多的数据,查询就会变得越慢。所以,以后看到select * 的时候,想一下是否可以在这里进行一些优化。

4、为每张表设置一个id作为其主键。这个id最好是一个int类型的,推荐使用unsigned,并将其设置为自动增加auto_increment。之前就出现过一个同事将varchar的字段作为主键的情况, 然后在数据量较大的时候,数据库这个环节速度变得不是很友好,所以尽量不要使用varchar来当主键,它会使得性能出现下降。而且在某些情况下,id这个主键字段是非常重要的。

5、使用enum而不是varchar。实际上,enum保存的是tinyint类型,但其显示为字符串。用这个字段来作一些选项列表就变得很合适了。比如你有一个字段,比如“性别”、“状态”或“所属部门”等,你知道这些字段的值是固定且有限的,那么可以考虑使用enum。对于性别这个字段,一般分为两种,有可能还有保密这种情况,我们可以使用数字1、2、3来分别表示这三张情况,而对于这些数字含义的区分则是业务层的事情了。我们需要将一些繁琐的需要计算的步骤全部放到业务层(或者说是服务层),因为系统的瓶颈在数据库,我们不能将过多的计算过程压到数据库上面去。数据库存储的数据应该尽量简单,但是,我们会在业务层结合具体的业务,对这些简单的数据进行分析。

6、尽可能的使用not null。除非你有一个很特别的原因要去使用null值,你应该总让你的字段保持为not null。

7、选择正确的存储引擎。myisam适合一些需要大量查询的应用。但其对于大量写操作并不是很好。因为它使用到的是表级锁,所以在你更新的时候,整张表都会被锁起来,试想一下,当你在更新某一行数据的时候,导致其他的行都无法被访问,这会不会 很难受呢。另外,myisam对于select count(*)这类操作的计算时很快的。而至于innodb而言,对于一些小的应用,它会比myisam还慢。它支持的是行级锁,于是写操作较多的时候,它会更加优秀。它还支持一些更高级的应用,比如说:事务。

8、拆为搜索的字段建立索引。不要以为只有标的逐渐可以建立索引,如果某个字段你总要拿来做搜索,那么为它简历索引吧。但是,不要以为建立索引,就可以为所欲为。其中有一些常用的规则需要去遵循以下的。

建立索引常用的规则

1、表的主键、外键必须有索引;

2、数据量超过300的表应该有索引;

3、经常与其他表进行连接的表,在连接字段上应该建立索引;

4、经常出现在Where子句中的字段,非凡是大表的字段,应该建立索引;

5、索引应该建在选择性高的字段上(枚举型字段不建索引);

6、索引应该建在小字段上,对于大的文本字段甚至超长字段,不要建索引;

7、复合索引的建立需要进行仔细分析;尽量考虑用单字段索引代替:

A、正确选择复合索引中的主列字段,一般是选择性较好的字段;

B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中?单字段查询是否极少甚至没有?假如是,则可以建立复合索引;否则考虑单字段索引;

C、假如复合索引中包含的字段经常单独出现在Where子句中,则分解为多个单字段索引;

D、假如复合索引所包含的字段超过3个,那么仔细考虑其必要性,考虑减少复合的字段;

E、假如既有单字段索引,又有这几个字段上的复合索引,一般可以删除复合索引;

8、频繁进行数据操作的表,不要建立太多的索引;

9、删除无用的索引,避免对执行计划造成负面影响;

以上是一些普遍的建立索引时的判定依据。一言以蔽之,索引的建立必须慎重,对每个索引的必要性都应该经过仔细分析,要有建立的依据。因为太多的索引与不充分、不正确的索引对性能都毫无益处:在表上建立的每个索引都会增加存储开销,索引对于插入、删除、更新操作也会增加处理上的开销。另外,过多的复合索引,在有单字段索引的情况下,一般都是没有存在价值的;相反,还会降低数据增加删除时的性能,凡是对频繁更新的表来说,负面影响更大.


当然还有很多其他的调优方法,例如读写分离,表分区等,后续会带大家更深入的了解。



全部评论: 0

    我有话说:

    阅读」从MySQL高可用架构看高可用架构设计

    高可用HA(High Availability)是分布式系统架构设计中必须考虑因素之一

    阅读」消息总线(MQ)多少

    消息总线(Message Queue,MQ),是一种跨进程通信机制,用于在上下游之间传递消息。MQ是一种常见上下游“逻辑解耦+物理解耦”消息通信服务,消息发送上游只需要依赖MQ,逻辑上和物理上

    阅读」图文并茂带了解分布式架构演进

    初始阶段架构初始阶段 小型系统 应用程序、数据库、文件等所有资源都在一台服务器上通俗称LAMP

    阅读」为什么在做微服务设计时候需要DDD?

    设计蓝图里为什么没有看到DDD影子呢?

    阅读」推荐系统中信息增强小技巧

    实用推荐系统构建经验,如何进行信息增强。

    阅读」如何构建可伸缩Web应用?

    可伸缩性已经成为Web应用程序DNA!

    阅读」阿里云-开放平台高级技术家教搭建微服务架构四大金刚利器

    孔凡勇,花名云狄,阿里云-开放平台高级技术家,对高并发、高性能、高可用、可伸缩分布式系统架构设计有丰富经验,Cloud Native坚定拥护者,坚守开发一线打磨匠艺架构师。

    阅读」轻松理解 Kubernetes 核心概念

    Kubernetes 迅速成为云环境中软件部署和管理新标准。

    阅读」大众点评是如何分表分库

    原大众点评订单单表早就已经突破两百G,由于查询维度较多,即使加了两个从库,优化索引,仍然存在很多查询不理想

    阅读」“做完”和“做好”区别

    在工作中,“做完”和“做好”虽然仅一字之差,但前者只是完成了某项工作,而后者则不仅是完成了工作还有一个好

    阅读」“来我公司做技术总监吧” “要写代码吗?” “不写代码来干嘛?”

    标题来源于一段真实对话,老赵,小李都是我朋友,我作为中间人介绍他们认识,我们约在上海码农圣地--张江某咖啡馆。

    阅读」移动端事件穿透原理与解决方案

    本文将带了解事件穿透及如何在实际项目中选择合适方案解决事件穿透问题。

    阅读」分布式事务四种解决方案,成长需要尝试

    分布式事务指事务操作位于不同节点上,需要保证事务 AICD 特性。

    阅读」移动端适配必须掌握基本概念和适配方案

    随着技术发展,移动设备越来越流行,并且不同设备间屏幕尺寸和屏幕像素差异,移动端开发面临着多分辨率适配问题。

    阅读」亿级用户分布式数据存储解决方案

    分布式数据库和分布式存储是分布式系统中难度最大、挑战最大,也是最容易出问题地方。互联网公司只有解决分布式数据存储问题,才能支撑更多次亿级用户涌入。

    阅读】为什么越来越多系统在做服务化?

    脱离业务实际情况架构都是耍流氓,所以不是所有系统都必须服务化,也不要为了服务化而服务化。