五个常见的优化SQL的技巧!

VSole2022-09-08 11:00:00

编程人员一定不陌生SQL语句吧,在我们日常写项目过程中,或多或少都会使用到SQL,SQL主要功能有增删改查,其中最常见的就是查询了,因此SQL语句的性能就变得至关重要,如何优化SQL呢?请看下文:

一、分解SQL

当我们遇到一个较复杂的SQL时,可以选择将它拆分成多个简单的SQL,这样既能保证处理结果,SQL也更简短了。

在面对超级复杂SQL语句时,性能提升尤为明显,推荐分解为小查询来进行优化,不过在应用设计时,如果一个查询能解决问题且不会产生性能问题,这是完全没问题的。

分解可以使缓存更高效,可以很方便地缓存单表查询结果对应的结果,执行单个查询也可以减少表锁的竞争,在程序应用层做关联,更容易对数据库进行拆分,也更容易做到高性能和可扩展。

二、查询切分

遇到结果集很大的查询,我们可以采用“分而治之”的思想,即将大查询切分为小查询,每个查询功能完全一样,只是各自完成一小部分,每次只返回一小部分的查询结果,类似于分页查询。

查询切分不管是对于SQL查询本身,还是对于上层业务来说,都是很小的开销。

三、执行计划

使用EXPLAIN关键字,可以让我们知道MYSQL是如何执行SQL语句的,可以帮助我们分析我们的查询语句或是表结构的性能瓶颈,EXPLAIN的查询结果还会告诉我们索引主键是如何被利用的,数据表示如何被搜索或排序的等等。

四、遵守原则

在我们平时写SQL时,养成良好习惯就可以很大程度上避免一些SQL性能问题。盘点以下几点:

a. 永远为每张表设置一个ID主键;

b. 避免使用SELECT *;

c. 为搜索字段建立索引;

d. 在Join表时使用对应类型的列,并将其索引;

e. 尽可能使用NOT NULL;

五、使用查询缓存

当有很多相同查询被执行多次时,这些结果往往会被放入一个缓存中,这样后续的相同查询就不用操作而直接访问缓存结果了。

MySQL查询缓存保存查询返回的完整结果。当查询命中该缓存,MySQL会like返回结果,跳过了解析、优化和执行截断。

这是提高查询性能最有效的方法之一,而且这是被MySQL引擎处理的,通常MySQL默认是不开启查询缓存的,需要手动开启。

sql优化优化
本作品采用《CC 协议》,转载必须注明作者和本文链接
在开始介绍如何优化sql前,先附上mysql内部逻辑图让大家有所了解连接器:?优先在缓存中进行查询,如果查到了则直接返回,如果缓存中查询不到,在去数据库中查询。
一、前言 在应用开发的早期,数据量少,开发人员开发功能时更重视功能上的实现,随着生产数据的增长,很多SQL语句开始暴露出性能问题,对生产的影响也越来越大,有时可能这些有问题的SQL就是整个系统性能的瓶颈。 二、SQL优化一般步骤 1、通过慢查日志等定位那些执行效率较低的SQL语句 2、explain 分析SQL的执行计划
背景我负责的系统到2021年初完成了功能上的建设,开始进入到推广阶段。随着推广的逐步深入,收到了很多好评的同时也收到了很多对性能的吐槽。作为一个优秀的后端程序员,这个数据肯定是不能忍的,我们马上就进入了漫长的接口优化之路。
国产数据库与Oracle在可观测性方面的差距
数据库的可观测性的学习榜样是Oracle,我们根据Oracle官方发布的资料以及可观测性接口就可以比较清晰的了解到数据库的运行状态,进行问题定位、性能分析的工作。目前国产数据库都没有提供如此丰富的可观测性接口与工具,因此对于国产数据库的运维来说,造成了很大的障碍。不知道今年的开发者大会上发布的openGauss商业版里,会不会看到USTORE成为默认存储引擎的功能。
在面对超级复杂SQL语句时,性能提升尤为明显,推荐分解为小查询来进行优化,不过在应用设计时,如果一个查询能解决问题且不会产生性能问题,这是完全没问题的。MySQL查询缓存保存查询返回的完整结果。当查询命中该缓存,MySQL会like返回结果,跳过了解析、优化和执行截断。这是提高查询性能最有效的方法之一,而且这是被MySQL引擎处理的,通常MySQL默认是不开启查询缓存的,需要手动开启。
如果关闭了autocommit,所有的sql语句都在一个事务中,直到执行了commit或rollback,该事务结束,并且开启了下一个事务。DML语句等都不会强制提交事务。因此与其说ACID是事务必须满足的条件,不如说它们是衡量事务的四个维度。undo log属于逻辑日志,它记录的是sql执行相关的信息。当发生回滚时,InnoDB会根据undo log做相反的事情,对于每个insert,回滚做delete;对于每个delete,回滚做insert;对于update,回滚会执行一个相反的update,把数据改回去。
存算一体SHARDING模式的分布式数据库最为典型的是Oceanbase。因为大型分布式计算环境下实施缓冲区融合成本极高,因此每个TIDB节点只能有本地缓冲,不能有全局缓冲。每个SET是一组高可用组,由一主多备组成。数据按照SET进行SHARDING分区。最初此类架构的主从切换类似于MYSQL的主从切换,对前端应用的影响很大,如果业务高峰时出现主DN故障,那就是灾难性的。
代表两个单引号的长度和一个单引号的长度不一致,表明可能存在注入。支持json格式,V1.9以上版本已支持json多层嵌套。支持cookie测试支持右键发送到插件扫描备注:右键发送一定需要有响应包,不然发不过去,这样才能对比和原数据包的长度。表示正在发送相关payload,end!?表示扫描完成且结果可能存在注入。变更 监控Proxy模式 为被动模式,提升交互体验感。算法:MD5,如果是post包,值变化也不会重新扫描,需要参数名变化才会再次扫描。
VSole
网络安全专家