0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

几个写SQL时常见的“坏毛病”及优化技巧

程序员cxuan 来源:程序员cxuan 2023-01-17 09:34 次阅读

今天给大家分享几个写 SQL 时常见的“坏毛病”及优化技巧。

1、LIMIT 语句

分页查询是最常用的场景之一,但也通常也是最容易出问题的地方。比如对于下面简单的语句,一般 DBA 想到的办法是在 type、 name、 create_time 字段上加组合索引。这样条件排序都能有效的利用到索引,性能迅速提升。

SELECT*
FROMoperation
WHEREtype='SQLStats'
ANDname='SlowLog'
ORDERBYcreate_time
LIMIT1000,10;

好吧,可能90%以上的 DBA 解决该问题就到此为止。但当 LIMIT 子句变成 “LIMIT 1000000,10” 时,程序员仍然会抱怨:我只取10条记录为什么还是慢?

要知道数据库也并不知道第1000000条记录从什么地方开始,即使有索引也需要从头计算一次。出现这种性能问题,多数情形下是程序员偷懒了。

在前端数据浏览翻页,或者大数据分批导出等场景下,是可以将上一页的最大值当成参数作为查询条件的。SQL 重新设计如下:

SELECT*
FROMoperation
WHEREtype='SQLStats'
ANDname='SlowLog'
ANDcreate_time>'2017-03-161400'
ORDERBYcreate_timelimit10;

2、隐式转换

SQL语句中查询变量和字段定义类型不匹配是另一个常见的错误。比如下面的语句:

mysql>explainextendedSELECT*
>FROMmy_balanceb
>WHEREb.bpn=14000000123
>ANDb.isverifiedISNULL;
mysql>showwarnings;
|Warning|1739|Cannotuserefaccessonindex'bpn'duetotypeorcollationconversiononfield'bpn'

其中字段 bpn 的定义为 varchar(20),MySQL 的策略是将字符串转换为数字之后再比较。函数作用于表字段,索引失效。

上述情况可能是应用程序框架自动填入的参数,而不是程序员的原意。现在应用框架很多很繁杂,使用方便的同时也小心它可能给自己挖坑。

3、关联更新、删除

虽然 MySQL5.6 引入了物化特性,但需要特别注意它目前仅仅针对查询语句的优化。对于更新或删除需要手工重写成 JOIN。

比如下面 UPDATE 语句,MySQL 实际执行的是循环/嵌套子查询(DEPENDENT SUBQUERY),其执行时间可想而知。

UPDATEoperationo
SETstatus='applying'
WHEREo.idIN(SELECTid
FROM(SELECTo.id,
o.status
FROMoperationo
WHEREo.group=123
ANDo.statusNOTIN('done')
ORDERBYo.parent,
o.id
LIMIT1)t);

执行计划:

+----+--------------------+-------+-------+---------------+---------+---------+-------+------+-----------------------------------------------------+
|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|
+----+--------------------+-------+-------+---------------+---------+---------+-------+------+-----------------------------------------------------+
|1|PRIMARY|o|index||PRIMARY|8||24|Usingwhere;Usingtemporary|
|2|DEPENDENTSUBQUERY||||||||ImpossibleWHEREnoticedafterreadingconsttables|
|3|DERIVED|o|ref|idx_2,idx_5|idx_5|8|const|1|Usingwhere;Usingfilesort|
+----+--------------------+-------+-------+---------------+---------+---------+-------+------+-----------------------------------------------------+

重写为 JOIN 之后,子查询的选择模式从 DEPENDENT SUBQUERY 变成 DERIVED,执行速度大大加快,从7秒降低到2毫秒。

UPDATEoperationo
JOIN(SELECTo.id,
o.status
FROMoperationo
WHEREo.group=123
ANDo.statusNOTIN('done')
ORDERBYo.parent,
o.id
LIMIT1)t
ONo.id=t.id
SETstatus='applying'

执行计划简化为:

+----+-------------+-------+------+---------------+-------+---------+-------+------+-----------------------------------------------------+
|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|
+----+-------------+-------+------+---------------+-------+---------+-------+------+-----------------------------------------------------+
|1|PRIMARY||||||||ImpossibleWHEREnoticedafterreadingconsttables|
|2|DERIVED|o|ref|idx_2,idx_5|idx_5|8|const|1|Usingwhere;Usingfilesort|
+----+-------------+-------+------+---------------+-------+---------+-------+------+-----------------------------------------------------+

4、混合排序

MySQL 不能利用索引进行混合排序。但在某些场景,还是有机会使用特殊方法提升性能的。

SELECT* 
FROMmy_ordero
INNERJOINmy_appraiseaONa.orderid=o.id
ORDERBYa.is_replyASC,
a.appraise_timeDESC
LIMIT0,20

执行计划显示为全表扫描:

+----+-------------+-------+--------+-------------+---------+---------+---------------+---------+-+
|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra
+----+-------------+-------+--------+-------------+---------+---------+---------------+---------+-+
|1|SIMPLE|a|ALL|idx_orderid|NULL|NULL|NULL|1967647|Usingfilesort|
|1|SIMPLE|o|eq_ref|PRIMARY|PRIMARY|122|a.orderid|1|NULL|
+----+-------------+-------+--------+---------+---------+---------+-----------------+---------+-+

由于 is_reply 只有0和1两种状态,我们按照下面的方法重写后,执行时间从1.58秒降低到2毫秒。

SELECT*
FROM((SELECT*
FROMmy_ordero
INNERJOINmy_appraisea
ONa.orderid=o.id
ANDis_reply=0
ORDERBYappraise_timeDESC
LIMIT0,20)
UNIONALL
(SELECT*
FROMmy_ordero
INNERJOINmy_appraisea
ONa.orderid=o.id
ANDis_reply=1
ORDERBYappraise_timeDESC
LIMIT0,20))t
ORDERBYis_replyASC,
appraisetimeDESC
LIMIT20;

5、EXISTS语句

MySQL 对待 EXISTS 子句时,仍然采用嵌套子查询的执行方式。如下面的 SQL 语句:

SELECT*
FROMmy_neighborn
LEFTJOINmy_neighbor_applysra
ONn.id=sra.neighbor_id
ANDsra.user_id='xxx'
WHEREn.topic_status< 4 
       AND EXISTS(SELECT 1 
                  FROM   message_info m 
                  WHERE  n.id = m.neighbor_id 
                         AND m.inuser = 'xxx')
ANDn.topic_type<>5

执行计划为:

+----+--------------------+-------+------+-----+------------------------------------------+---------+-------+---------+-----+
|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|
+----+--------------------+-------+------+-----+------------------------------------------+---------+-------+---------+-----+
|1|PRIMARY|n|ALL||NULL|NULL|NULL|1086041|Usingwhere|
|1|PRIMARY|sra|ref||idx_user_id|123|const|1|Usingwhere|
|2|DEPENDENTSUBQUERY|m|ref||idx_message_info|122|const|1|Usingindexcondition;Usingwhere|
+----+--------------------+-------+------+-----+------------------------------------------+---------+-------+---------+-----+

去掉 exists 更改为 join,能够避免嵌套子查询,将执行时间从1.93秒降低为1毫秒。

SELECT*
FROMmy_neighborn
INNERJOINmessage_infom
ONn.id=m.neighbor_id
ANDm.inuser='xxx'
LEFTJOINmy_neighbor_applysra
ONn.id=sra.neighbor_id
ANDsra.user_id='xxx'
WHEREn.topic_status< 4 
       AND n.topic_type <>5

新的执行计划:

+----+-------------+-------+--------+-----+------------------------------------------+---------+-----+------+-----+
|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|
+----+-------------+-------+--------+-----+------------------------------------------+---------+-----+------+-----+
|1|SIMPLE|m|ref||idx_message_info|122|const|1|Usingindexcondition|
|1|SIMPLE|n|eq_ref||PRIMARY|122|ighbor_id|1|Usingwhere|
|1|SIMPLE|sra|ref||idx_user_id|123|const|1|Usingwhere|
+----+-------------+-------+--------+-----+------------------------------------------+---------+-----+------+-----+

6、条件下推

外部查询条件不能够下推到复杂的视图或子查询的情况有:

  • 聚合子查询;
  • 含有 LIMIT 的子查询;
  • UNION 或 UNION ALL 子查询;
  • 输出字段中的子查询;

如下面的语句,从执行计划可以看出其条件作用于聚合子查询之后

SELECT*
FROM(SELECTtarget,
Count(*)
FROMoperation
GROUPBYtarget)t
WHEREtarget='rm-xxxx'
+----+-------------+------------+-------+---------------+-------------+---------+-------+------+-------------+
|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|
+----+-------------+------------+-------+---------------+-------------+---------+-------+------+-------------+
|1|PRIMARY||ref|||514|const|2|Usingwhere|
|2|DERIVED|operation|index|idx_4|idx_4|519|NULL|20|Usingindex|
+----+-------------+------------+-------+---------------+-------------+---------+-------+------+-------------+

确定从语义上查询条件可以直接下推后,重写如下:

SELECTtarget,
Count(*)
FROMoperation
WHEREtarget='rm-xxxx'
GROUPBYtarget

执行计划变为:

+----+-------------+-----------+------+---------------+-------+---------+-------+------+--------------------+
|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|
+----+-------------+-----------+------+---------------+-------+---------+-------+------+--------------------+
|1|SIMPLE|operation|ref|idx_4|idx_4|514|const|1|Usingwhere;Usingindex|
+----+-------------+-----------+------+---------------+-------+---------+-------+------+--------------------+

7、提前缩小范围

先上初始 SQL 语句:

SELECT*
FROMmy_ordero
LEFTJOINmy_userinfou
ONo.uid=u.uid
LEFTJOINmy_productinfop
ONo.pid=p.pid
WHERE(o.display=0)
AND(o.ostaus=1)
ORDERBYo.selltimeDESC
LIMIT0,15

该SQL语句原意是:先做一系列的左连接,然后排序取前15条记录。从执行计划也可以看出,最后一步估算排序记录数为90万,时间消耗为12秒。

+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+----------------------------------------------------+
|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|
+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+----------------------------------------------------+
|1|SIMPLE|o|ALL|NULL|NULL|NULL|NULL|909119|Usingwhere;Usingtemporary;Usingfilesort|
|1|SIMPLE|u|eq_ref|PRIMARY|PRIMARY|4|o.uid|1|NULL|
|1|SIMPLE|p|ALL|PRIMARY|NULL|NULL|NULL|6|Usingwhere;Usingjoinbuffer(BlockNestedLoop)|
+----+-------------+-------+--------+---------------+---------+---------+-----------------+--------+----------------------------------------------------+

由于最后 WHERE 条件以及排序均针对最左主表,因此可以先对 my_order 排序提前缩小数据量再做左连接。SQL 重写后如下,执行时间缩小为1毫秒左右。

SELECT*
FROM(
SELECT*
FROMmy_ordero
WHERE(o.display=0)
AND(o.ostaus=1)
ORDERBYo.selltimeDESC
LIMIT0,15
)o
LEFTJOINmy_userinfou
ONo.uid=u.uid
LEFTJOINmy_productinfop
ONo.pid=p.pid
ORDERBYo.selltimeDESC
limit0,15

再检查执行计划:子查询物化后(select_type=DERIVED)参与 JOIN。虽然估算行扫描仍然为90万,但是利用了索引以及 LIMIT 子句后,实际执行时间变得很小。

+----+-------------+------------+--------+---------------+---------+---------+-------+--------+----------------------------------------------------+
|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|
+----+-------------+------------+--------+---------------+---------+---------+-------+--------+----------------------------------------------------+
|1|PRIMARY||ALL|NULL|NULL|NULL|NULL|15|Usingtemporary;Usingfilesort|
|1|PRIMARY|u|eq_ref|PRIMARY|PRIMARY|4|o.uid|1|NULL|
|1|PRIMARY|p|ALL|PRIMARY|NULL|NULL|NULL|6|Usingwhere;Usingjoinbuffer(BlockNestedLoop)|
|2|DERIVED|o|index|NULL|idx_1|5|NULL|909112|Usingwhere|
+----+-------------+------------+--------+---------------+---------+---------+-------+--------+----------------------------------------------------+

8、中间结果集下推

再来看下面这个已经初步优化过的例子(左连接中的主表优先作用查询条件):

SELECTa.*,
c.allocated
FROM(
SELECTresourceid
FROMmy_distributed
WHEREisdelete=0
ANDcusmanagercode='1234567'
ORDERBYsalecodelimit20)a
LEFTJOIN
(
SELECTresourcesid,sum(ifnull(allocation,0)*12345)allocated
FROMmy_resources
GROUPBYresourcesid)c
ONa.resourceid=c.resourcesid

那么该语句还存在其它问题吗?不难看出子查询 c 是全表聚合查询,在表数量特别大的情况下会导致整个语句的性能下降。

其实对于子查询 c,左连接最后结果集只关心能和主表 resourceid 能匹配的数据。因此我们可以重写语句如下,执行时间从原来的2秒下降到2毫秒。

SELECTa.*,
c.allocated
FROM(
SELECTresourceid
FROMmy_distributed
WHEREisdelete=0
ANDcusmanagercode='1234567'
ORDERBYsalecodelimit20)a
LEFTJOIN
(
SELECTresourcesid,sum(ifnull(allocation,0)*12345)allocated
FROMmy_resourcesr,
(
SELECTresourceid
FROMmy_distributed
WHEREisdelete=0
ANDcusmanagercode='1234567'
ORDERBYsalecodelimit20)a
WHEREr.resourcesid=a.resourcesid
GROUPBYresourcesid)c
ONa.resourceid=c.resourcesid

但是子查询 a 在我们的SQL语句中出现了多次。这种写法不仅存在额外的开销,还使得整个语句显的繁杂。使用 WITH 语句再次重写:

WITHaAS
(
SELECTresourceid
FROMmy_distributed
WHEREisdelete=0
ANDcusmanagercode='1234567'
ORDERBYsalecodelimit20)
SELECTa.*,
c.allocated
FROMa
LEFTJOIN
(
SELECTresourcesid,sum(ifnull(allocation,0)*12345)allocated
FROMmy_resourcesr,
a
WHEREr.resourcesid=a.resourcesid
GROUPBYresourcesid)c
ONa.resourceid=c.resourcesid

总结

数据库编译器产生执行计划,决定着SQL的实际执行方式。但是编译器只是尽力服务,所有数据库的编译器都不是尽善尽美的。

上述提到的多数场景,在其它数据库中也存在性能问题。了解数据库编译器的特性,才能避规其短处,写出高性能的SQL语句。

程序员在设计数据模型以及编写SQL语句时,要把算法的思想或意识带进来。

编写复杂SQL语句要养成使用 WITH 语句的习惯。简洁且思路清晰的SQL语句也能减小数据库的负担 。

审核编辑 :李倩


声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • SQL
    SQL
    +关注

    关注

    1

    文章

    760

    浏览量

    44079
  • 数据库
    +关注

    关注

    7

    文章

    3766

    浏览量

    64278
  • 编译器
    +关注

    关注

    1

    文章

    1618

    浏览量

    49052

原文标题:这样写 SQL,差点人没了

文章出处:【微信号:cxuangoodjob,微信公众号:程序员cxuan】欢迎添加关注!文章转载请注明出处。

收藏 人收藏

    评论

    相关推荐

    SQL错误代码及解决方案

    SQL数据库开发和管理中,常见的错误代码及其解决方案可以归纳如下: 一、语法错误(Syntax Errors) 错误代码 :无特定代码,但通常会在错误消息中明确指出是语法错误。 原因 :SQL语句
    的头像 发表于 11-19 10:21 468次阅读

    SQL与NoSQL的区别

    在信息技术领域,数据库是存储和管理数据的核心组件。随着互联网的发展和大数据时代的到来,对数据库的需求也在不断变化。SQL和NoSQL作为两种主流的数据库管理系统,各自有着独特的优势和应用场
    的头像 发表于 11-19 10:15 105次阅读

    大数据从业者必知必会的Hive SQL调优技巧

    不尽人意。本文针对Hive SQL的性能优化进行深入研究,提出了一系列可行的调优方案,并给出了相应的优化案例和优化前后的SQL代码。通过合理
    的头像 发表于 09-24 13:30 183次阅读

    QPS提升10倍的sql优化

    本次慢sql优化是大促准备时的一个优化优化4c16g单实例mysql支持QPS从437到4610,今天发文时618大促已经顺利结束,该mysql库和应用在整个大促期间运行也非常稳定。
    的头像 发表于 08-21 11:12 297次阅读
    QPS提升10倍的<b class='flag-5'>sql</b><b class='flag-5'>优化</b>

    IP 地址在 SQL 注入攻击中的作用及防范策略

    数据库在各个领域的逐步应用,其安全性也备受关注。SQL 注入攻击作为一种常见的数据库攻击手段,给网络安全带来了巨大威胁。今天我们来聊一聊SQL 注入攻击的基本知识。 SQL 注入攻击的
    的头像 发表于 08-05 17:36 268次阅读

    什么是 Flink SQL 解决不了的问题?

    简介 在实时数据开发过程中,大家经常会用 Flink SQL 或者 Flink DataStream API 来做数据加工。通常情况下选用2者都能加工出想要的数据,但是总会有 Flink SQL
    的头像 发表于 07-09 20:50 269次阅读

    甲骨文发布AI编程助手,助用户编写Java、SQL程序

    据悉,Oracle Code Assist基于甲骨文先进的云计算平台——Oracle Cloud Infrastructure (OCI)构建,重点优化各项Java、SQL程序以及OCI应用开发环节。
    的头像 发表于 05-13 10:19 493次阅读

    常见串口通信的几个问题请教?

    有关常见串口通信的几个问题请教论坛里的专家? 1、常见串口通信CAN,DP,PN,ETHER IP/TCP,ETHERCAT等,这些串口协议的终端电阻分别是多少? 2、这些终端电阻是为了阻抗匹配
    发表于 04-04 16:30

    SQL全外连接剖析

    SQL中的全外连接是什么? 在SQL中,FULLOUTERJOIN组合左外连接和右外连接的结果,并返回连接子句两侧表中的所有(匹配或不匹配)行。接下面sojson给大家详细讲解。   图解:SQL
    的头像 发表于 03-19 18:28 2148次阅读
    <b class='flag-5'>SQL</b>全外连接剖析

    电子束光刻的参数优化常见问题介绍

    本文从光刻图案设计、特征尺寸、电镜参数优化等方面介绍电子束光刻的参数优化,最后介绍了一些常见问题。
    的头像 发表于 03-17 14:33 960次阅读
    电子束光刻的参数<b class='flag-5'>优化</b>及<b class='flag-5'>常见</b>问题介绍

    SQL对象名无效的解决方法

    使用的对象名称,确保其有效性。本文将详细介绍SQL对象名无效的解决方法。 1. 检查对象名称的正确性 首先,需要检查使用的对象名称是否正确。常见的错误包括拼写错误、大小写错误、使用了无效字符等。请确保对象名称与数据库中的实际对象名称
    的头像 发表于 12-29 14:45 1657次阅读

    MySQL的执行过程 SQL语句性能优化常用策略

    回顾 MySQL 的执行过程,帮助介绍如何进行 sql 优化
    的头像 发表于 12-12 10:26 625次阅读
    MySQL的执行过程 <b class='flag-5'>SQL</b>语句性能<b class='flag-5'>优化</b>常用策略

    MySQL执行过程:如何进行sql 优化

    (1)客户端发送一条查询语句到服务器; (2)服务器先查询缓存,如果命中缓存,则立即返回存储在缓存中的数据; (3)未命中缓存后,MySQL 通过关键字将 SQL 语句进行解析,并生成一颗对应的解析树,MySQL 解析器将使用 MySQL 语法进行验证和解析。
    的头像 发表于 12-12 10:19 383次阅读
    MySQL执行过程:如何进行<b class='flag-5'>sql</b> <b class='flag-5'>优化</b>

    oracle执行sql查询语句的步骤是什么

    Oracle数据库是一种常用的关系型数据库管理系统,具有强大的SQL查询功能。Oracle执行SQL查询语句的步骤包括编写SQL语句、解析SQL语句、生成执行计划、执行
    的头像 发表于 12-06 10:49 898次阅读

    oracle sql 定义变量并赋值

    在Oracle SQL中,变量是用来存储数据值的标识符。通过定义和使用变量,我们可以在SQL语句中使用它们来存储和处理数据,从而实现更灵活和动态的查询和操作。 在Oracle SQL中,定义变量并
    的头像 发表于 12-06 10:46 2699次阅读