数据库 
首页 > 数据库 > 浏览文章

MySQL优化SQL语句的技巧

(编辑:jimmy 日期: 2024/11/26 浏览:3 次 )

在面对不够优化、或者性能极差的SQL语句时,我们通常的想法是将重构这个SQL语句,让其查询的结果集和原来保持一样,并且希望SQL性能得以提升。而在重构SQL时,一般都有一定方法技巧可供参考,本文将介绍如何通过这些技巧方法来重构SQL。

一、分解SQL

有时候对于一个复杂SQL,我们首先想到的是是否需要将一个复杂SQL分解成多个简单SQL,来完成相同业务处理结果。

在以前,大家总是强调需要数据库层来完成尽可能的工作,这也就不难理解在一些老的产品、项目中时常会看见很多超级复杂、超级长的SQL语句,这样做的逻辑在以前认为多次交互,在网络带宽、程序与数据库间网络通信等方面是一件代价很高的事情。然后在现在,无论是带宽还是延迟,网络速度比以前要快的很多,多次交互也没有太大的问题。即使在一个通用服务器上,也能够运行每秒超过10万的查询,所以运行多个小查询现在已经不是大问题了。

复杂SQL的分解,在面对超级复杂SQL语句时,性能提升尤为明显。所以,在面对超级复杂SQL语句,并且存在性能问题时,推荐分解为小查询来进行优化

不过,在应用设计的时候,如果一个查询能够胜任并且不会产生性能问题,这时完全可以用一个稍微复杂的SQL来完成的,倘若再死板的强制拆分成多个小查询是不明智的。

在当今很多高性能的应用系统中,都是极力推荐使用单表操作,然后将单表查询结果在应用程序中进行关联,以满足复杂业务的查询需求。一个SQL可以搞定事情,为何要分开来写,而且还得在应用程序中多次执行SQL查询,再进行结果集的关联,这到底为什么要这么做呢?

乍一看,这样做复杂不说而且没有什么好处,原本一条查询,这样却变成了多条查询。事实上,这样分解有如下的优势:

  • 让缓存更高效。在应用程序中,可以很方便地缓存单表查询结果对应的结果对象,便于后续任何时候可以直接从结果对象中获取数据。
  • 分解查询后,执行单个查询可以减少表锁的竞争。
  • 在程序应用层做关联,可以更容易对数据库进行拆分,更容易做到高性能和可扩展。
  • 单表查询效率高于多表复杂查询。
  • 减少冗余记录的查询。在程序应用层关联,意味着对于某条记录应用只需要查询一次,而在数据库中做关联查询,则可能需要重复地访问一部分数据记录。从这点来看,这样的重构还可能减少网络和内存的消耗。

二、查询切分

有时候对于一个大查询,即:结果集很大的查询,我们需要采用“分而治之”的思想,将大查询切分为小查询,每个查询功能完全一样,只是完成一小部分,每次只返回一小部分查询结果。通俗来讲,就是对where条件的过滤范围进行切分,每次只查询其中一部分数据,即:类似于分页查询。

这样做,不管对于SQL查询本身,还是对于上层业务来说,都是很小的开销。最典型的的案例就是分页查询,目前各类框架都有了很好的支持,如:MyBatis等,只需在实际使用时稍加留意就可避免。

三、执行计划

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

语法格式是:

EXPLAIN SELECT语句;

通过执行计划结果,将会指导我们进一步来重构SQL语句,如:增加索引、调整索引顺序、避免使用某些函数等等。

关于执行计划,后续章节将会单独详细讲解。

四、遵守原则

在平时写SQL时,养成好的习惯,多加留意,很大程度上就会避免一些SQL性能问题。汇总如下:

  • 永远为每张表设置一个ID主键。
  • 避免使用SELECT *。
  • 为搜索字段建立索引。
  • 在Join表的时候使用对应类型的列,并将其索引。
  • 尽可能的使用NOT NULL。
  • 越小的列会越快。
  • 当只要一行数据时使用LIMIT 1。
  • 操作符的优化,尽量不采用不利于索引的操作符,目的就是为了避免全表扫描。

             1)in 和not in慎用,尽量用between代替in,用 not exists 代替 not in
             2)is null和is not null慎用
             3)!=或<>操作符能不用就不用,否则将使引擎放弃使用索引而进行全表扫描。

五、使用查询缓存

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

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

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

查询缓存对应用程序是完全透明的。应用程序无需关心MySQL是通过查询返回的还是实际执行返回的结果。事实上,这两种方式执行的结果是完全相同的。换句话说,查询缓存无需使用任何语法。

随着现在的通用服务器越来越强大,查询缓存被发现是一个影响服务器扩展性的因素。它可能成为整个服务器的资源竞争单点,在多核服务器上还可能导致服务器僵死。所以大部分时候应该默认关闭查询缓存,如果查询缓存作用很大的话,可以配置个几十兆的小缓存空间。(在选择时,需要进行权衡)

关于查询缓存有如下参数可供配置:

  • query_cache_type

是否打开查询缓存。可以设置OFF、ON、DEMAND,DEMAND表示只有在查询语句中明确写入sql_cache的语句才放入查询缓存。

  • query_cache_size

查询缓存使用的总内存空间,单位是字节。这个值必须是1024的整倍数,否则实际分配的数据会和指定的大小有区别。

  • query_cache_min_res_unit

在查询缓存中分配内存块时的最小单位。

  • query_cache_limit

缓存的最大查询结果。如果查询结果大于这个值,则不会被缓存。因为查询缓存在数据生成的时候就开始尝试缓存数据,所以只有当结果全部返回后,MySQL才知道查询结果是否超出限制。

关于查询缓存,后续章节将会单独详细讲解。

以上就是MySQL优化SQL语句的技巧的详细内容,更多关于MySQL优化sql语句的资料请关注其它相关文章!

上一篇:关于MySQL主从复制的几种复制方式总结
下一篇:mysql不是内部命令的错误解决方案
一句话新闻
一文看懂荣耀MagicBook Pro 16
荣耀猎人回归!七大亮点看懂不只是轻薄本,更是游戏本的MagicBook Pro 16.
人们对于笔记本电脑有一个固有印象:要么轻薄但性能一般,要么性能强劲但笨重臃肿。然而,今年荣耀新推出的MagicBook Pro 16刷新了人们的认知——发布会上,荣耀宣布猎人游戏本正式回归,称其继承了荣耀 HUNTER 基因,并自信地为其打出“轻薄本,更是游戏本”的口号。
众所周知,寻求轻薄本的用户普遍更看重便携性、外观造型、静谧性和打字办公等用机体验,而寻求游戏本的用户则普遍更看重硬件配置、性能释放等硬核指标。把两个看似难以相干的产品融合到一起,我们不禁对它产生了强烈的好奇:作为代表荣耀猎人游戏本的跨界新物种,它究竟做了哪些平衡以兼顾不同人群的各类需求呢?
友情链接:杰晶网络 DDR爱好者之家 南强小屋 黑松山资源网 白云城资源网 网站地图 SiteMap