技术分享 | 又是一条慢 SQL 改写，拿捏！

耍娃儿 2023-07-12 16:36:24  54703

分类专栏：资讯

1背景

开发同学丢了一条 SQL 过来。“马哥，看看这个 SQL 能否优化，业务那边反馈很慢！”看了下执行计划+表结构，索引都没问题。那到底是怎么回事呢？咱们一起来瞧瞧。

2分析原 SQL

explain SELECT
        count(0)
FROM
        invoice_sales_application a
WHERE
        (
                shop_order_id LIKE '23060919546335%'
                OR (
                        EXISTS (
                                SELECT
                                        1
                                FROM
                                        invoice_sales_application_detail b
                                WHERE
                                        a.application_no = b.application_no
                                AND a.invoice_category = b.invoice_category
                                AND b.del_flag = 0
                                AND b.shop_order_id LIKE '23060919546335%'
                        )
                        AND a.is_merge = 1
                )
        )

先来看看这个 SQL 是什么意思：

在 invoice_sales_application 表中，shop_order_id 以 '23060919546335%'开头，或者存在一个相关的 invoice_sales_application_detail 表中的记录，该记录的 application_no 和 invoice_category 与 invoice_sales_application 表中的相同，并且 shop_order_id 以 '23060919546335%' 开头，同时 invoice_sales_application 表中的 is_merge 字段为 1。

执行计划：all+ref，其中 a 表要扫描 116w 行的数据。

执行需要 43s，且有一个全表扫描。

3优化操作

EXISTS 转化成 JOIN 的方式

这里是把 EXISTS 改写成 INNER JOIN 通过索引关键关联，应该会有不错的效果，试试看。

SELECT  count(0)
FROM invoice_sales_application a INNER
JOIN invoice_sales_application_detail b
  ON a.application_no = b.application_no
WHERE ( a.shop_order_id LIKE '23060919546335%'
    OR ( b.shop_order_id LIKE '23060919546335%'
    AND a.is_merge = 1 ) )
    AND a.invoice_category = b.invoice_category
    AND b.del_flag = 0

这里虽然转化了 INNER JOIN 的方式，执行计划还是 all+ref ，因为用了 OR 导致 a 表没有用上索引，还是用的全表扫描。没关系，咱们再次进行转化。

OR 改成 UNION

 SELECT count(*)
 FROM invoice_sales_application a
 INNER JOIN invoice_sales_application_detail b ON a.application_no = b.application_no
 AND a.invoice_category = b.invoice_category
 AND b.del_flag = 0
 WHERE a.shop_order_id = '23060919546335'
 AND a.del_flag = 0
 UNION
 SELECT count(*)
 FROM invoice_sales_application a
 INNER JOIN invoice_sales_application_detail b ON a.application_no = b.application_no
 AND a.invoice_category = b.invoice_category
 AND b.del_flag = 0
 WHERE b.shop_order_id = '23060919546335'
 AND a.is_merge = 1
 AND a.del_flag = 0;

在看看执行计划，eq_ref+ref+ref+ref。说明已经优化的很好了，起码没有全表扫描。

最后看看结果。

这样 SQL 执行很快了，查询时间从 42s 降到 18ms，快了几个数量级。

4小结

1、当 SQL 的主架构中含有 EXISTS 的时候，可以改成 INNER JOIN 的方式，先看看效果。

2、当条件中有 OR 的时候，可以改成 UNION 试试。

本文关键字：#MySQL# #SQL优化#

活动推荐：

【深圳 7.15】ActionDB 与您相约 OB Cloud 公开课开放麦环节

【北京 7.21】爱可生邀您参加 Gdevops 全球敏捷运维峰会北京站

文章推荐：

技术分享 | OceanBase 慢查询排查思路

故障分析 | MySQL：我的从库竟是我自己！？

故障分析 | 一个 Kill 不掉的 MySQL 会话

技术分享 | OceanBase写入限速源码解读

故障分析 | innodb_thread_concurrency 导致数据库异常的问题分析

故障分析 | OceanBase 频繁更新数据后读性能下降的排查

故障分析 | MySQL 升级到 8.0 变慢问题分析

技术分享 | 一招解决 MySQL 中 DDL 被阻塞的问题

故障分析 | 一条本该记录到慢日志的 SQL 是如何被漏掉的

关于 SQLE

爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者，支持多场景审核，支持标准化上线流程，原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。

SQLE 获取

类型	地址
版本库	https://github.com/actiontech/sqle
文档	https://actiontech.github.io/sqle-docs/
发布信息	https://github.com/actiontech/sqle/releases
数据审核插件开发文档	https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_auditplugin/auditplugin_development.html

提交有效 pr，高质量 issue，将获赠面值 200-500 元（具体面额依据质量而定）京东卡以及爱可生开源社区精美周边！

更多关于 SQLE 的信息和交流，请加入官方QQ交流群：637150065

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接：https://www.xckfsq.com/news/show.html?id=26184

赞同 0

评论 0 条

技术分享 | 又是一条慢 SQL 改写，拿捏！

1背景

2分析原 SQL

3优化操作

EXISTS 转化成 JOIN 的方式

OR 改成 UNION

4小结

相关文章

关注我们