【干货实战】SQL太慢,教你调优三板斧-Select篇

文章初衷

我们发现在体系上线初期，SQL运行都是正常的，但是到了业务稳定运行以后，在数据量达到一定水平，我们会发现越来越多的慢SQL出现，严重影响用户体验。
目录
文章初衷
慢SQL的定义
⚠️留意：后两个案例更出色！
【实战】
慢SQL调优---三板斧第一招【由内到外】

慢SQL调优---三板斧第二招【小表驱动大表】
原始SQL
调解次序
慢SQL调优---三板斧第三招【条件前置】
原始SQL
优化后的语句
想知道本篇文章是否对您有帮助，让我有更新下一篇的动力。如果有帮助可以批评“有”，非常感谢各位观众老爷们！

---

慢SQL的定义

慢SQL，即执行时间较长的SQL查询语句，通常指的是在数据库管理体系中执行时间超过预设阈值的SQL语句。这个阈值可以由数据库管理员根据体系性能和业务需求来设定，常见的阈值可能是2秒、5秒或更长。当一个SQL查询的执行时间超过了这个阈值，它就会被标志为“慢查询”。
慢SQL的存在可能表明数据库性能存在瓶颈，如索引设计不合理、查询逻辑复杂、数据量过大、硬件资源不足等题目。它们会占用更多的CPU、I/O资源，影响数据库的响应速度，低落团体体系性能，乃至导致体系响应耽误或崩溃。
为了优化慢SQL，数据库管理员和开发人员通常必要对其举行详细的分析，包括检察执行筹划、查抄索引使用情况、优化查询语句布局、调解数据库参数等，以提高查询效率和体系性能。别的，定期检察慢查询日志也是发现和解决慢SQL题目标有效本领。
请耐心看完，包管你的优化思路会更加清晰。
⚠️留意：后两个案例更出色！


最后附上《30个业务场景的SQL优化》、《老司机总结的12条 SQL 优化方案》

【实战】

慢SQL调优---三板斧第一招【由内到外】

话不多说，我们进入实战，以下是我们生产环境的一段查询SQL，它运行耗时在157.84秒，那么各人可以想一想，如果是你，看到这一段SQL会怎么入手呢？
原始SQL

1. SELECT CL.SCRQSTR,
2.         TEAM.TEAMCODE AS BMID,
3.         O.BATCHNO,
4.         O.STYLE_NO,
5.         O.PO_ID,
6.         SUM(CL.QTY)AS QTY,
7.         MX.MXBRS,
8.         MXBGS.WORK_SEC AS MXGS,
9.         O.ORDERTYPE,
10.         O.FACTORY_NAME,
11.         O.DIC_ORDER_NO,
12.         O.DIC_ROW_NO,
13.         O.ORDER_NO FROM
14.     (SELECT DISTINCT SCRQSTR,
15.         QTY,
16.         LSXNO,
17.         ORDER_NO,
18.         PROCESSID,
19.         BID
20.     FROM T_DG_CLXX
21.     WHERE CREATE_DATE>='2024-06-21 13:20:00'
22.             AND CREATE_DATE<'2024-06-21 13:30:00')CL
23. INNER JOIN T_TEAM_SUSPEND T1
24.     ON T1.LSXNO=CL.LSXNO
25. INNER JOIN T_BASIC_TEAM TEAM
26.     ON TEAM.ID=T1.ID
27. INNER JOIN T_PRODUCTION_ORDER O
28.     ON O.ORDER_NO=CL.ORDER_NO
29. INNER JOIN PROCESS_PATH PATH
30.     ON PATH.CID=CL.PROCESSID
31.         AND PATH.PO_ID=O.PO_ID
32.         AND PATH.WORKID=3
33. INNER JOIN
34.     (SELECT COUNT(*)AS MXBRS,
35.         T.ORDER_NO FROM
36.         (SELECT DISTINCT USERID,
37.         ORDER_NO
38.         FROM T_DG_CLXX
39.         WHERE CREATE_DATE>='2024-06-21 13:20:00'
40.                 AND CREATE_DATE<'2024-06-21 13:30:00'
41.                 AND LSXNO NOT IN(1,16))T
42.         GROUP BY  T.ORDER_NO)MX
43.         ON MX.ORDER_NO=CL.ORDER_NO
44. INNER JOIN
45.     (SELECT SUM(CASE
46.         WHEN T.WORK_SEC>600 THEN
47.         600
48.         WHEN T.WORK_SEC<10 THEN
49.         150
50.         ELSE T.WORK_SEC END)AS WORK_SEC,ORDER_NO FROM
51.         (SELECT DISTINCT SCRQ,
52.         WORK_SEC,
53.         MODULE_ID,
54.         SEAT_CODE,
55.         PIECES,
56.         USERID,
57.         LSXNO,
58.         ORDER_NO
59.         FROM T_DG_CLXX
60.         WHERE CREATE_DATE>='2024-06-21 13:20:00'
61.                 AND CREATE_DATE<'2024-06-21 13:30:00'
62.                 AND LSXNO NOT IN(1,16))T
63.         GROUP BY  T.ORDER_NO)MXBGS
64.         ON MXBGS.ORDER_NO=CL.ORDER_NO
65. GROUP BY  CL.SCRQSTR,TEAM.TEAMCODE,O.BATCHNO,O.STYLE_NO,O.PO_ID,MX.MXBRS,MXBGS.WORK_SEC,O.ORDERTYPE,O.FACTORY_NAME,O.DIC_ORDER_NO,O.DIC_ROW_NO,O.ORDER_NO

复制代码

你是不是也以为很棘手？感觉有业务逻辑，关联了很多表，也有很多子查询。



首先我们可以先对SQL中的子查询举行执行，看是否存在慢SQL，从内到外去剖析。比如以上这段SQL可以单独执行子查询，检察所需耗时。
首先第一个子查询,但是我们不知道这个表有多少数据量，以是我们必要截取前面10条即可，mysql添加条件limit 10,如果是Oracle就是where rownum < 11，执行发现，SQL超过30秒都没有出结果。

1. SELECT DISTINCT SCRQSTR,
2.         QTY,
3.         LSXNO,
4.         ORDER_NO,
5.         PROCESSID,
6.         BID
7.     FROM T_DG_CLXX
8.     WHERE CREATE_DATE>='2024-06-21 13:20:00'
9.             AND CREATE_DATE<'2024-06-21 13:30:00' LIMIT 10;

复制代码

因此可以判断这个SQL语句异常，可以通过EXPLAIN 来检察是否走索引了，再看一下T_DG_CLXX表有多少数据量。
通过EXPLAIN发现SQL没有走索引，说明CREATE_DATE字段没有建立索引。另外查询发现此表有3700万条数据量，也发现此表会每年举行数据归档，必须保留1年数据。

那么小同伴知道接下来要做什么了吗？

--------------------------------------------------------------------------------------

没错，建立索引！
建立索引以后，查询为0.1秒左右。
然后将原先业务SQL重新执行，查询时间为0.135秒，效率提升1169倍

这个案例很简朴，CREATE_DATE字段由于是后面业务必要，属于新增的字段。增长字段忘记增长索引，后面出现题目过一次，但是研发又忘记添加索引了，后面我们运维团队通过慢SQL预警发现了这条SQL异常。

慢SQL调优---三板斧第二招【小表驱动大表】

前面谁人案例是不是很简朴，下面这个看到调优结果也会以为很简朴，但是很经典。
给我一个支点，我能翘起整个