用ChatGPT帮我进行SQL调优，sql 调优再也没有那么难了

文章目录

问题背景

近期由于订单量激增，我们的 ERP 系统

订单查询效率骤降！

查询半年内的 300万数据就要卡到 50多秒才能出结果（有时要一分多钟）。 而订单查询这块由于系统迭代原因，导致查询条件十分复杂，

索引也已经优化到了极限，不能再通过加索引解决问题。

实际业务中，相信很多人也都有 SQL 调优经验，这个问题也有大神能解决。 但是如今有了 ChatGPT，可以大大提升我们解决此类问题的效率，下面我给大家分享一下如何实操：

先看一下调整前的 sql

SELECT a.*, b.poId, d.orderId, d.problemReason, d.workOrderType
    , d.remark, d.afterSaleCost, d.cause, d.logisticsCosts, d.logisticsType
    , d.shipmentOA, d.otherFee, d.causeText, d.afterSaleDealCode, d.afterSaleDealName
    , bo.jyyOppCode AS jyyOppCode, bo.jyyOppName AS jyyOppName, bo.customerName AS customerName
FROM ordermaininfo a
    LEFTJOIN ordersubinfo b ON a.mainId = b.mainId
    LEFTJOIN bizoppinfo bo ON bo.busOppCode = a.busOppCode
        AND bo.validStatus ='1'LEFTJOIN orderaftersalesinfo d ON a.id = d.orderId
WHERE1=1AND a.orderCreateDate BETWEEN'2022-12-20 00:00:00'AND'2023-04-27 23:59:59'AND a.returnOrderFlag ='0'AND a.isToKthree NOTIN('5','10')AND a.submitFlag ='1'AND a.validStatus ='1'GROUPBY a.mainId
ORDERBY a.customOrderId ASC, a.mainId ASC, a.orderCreateDate desc;

功能说明

- customOrderId、mainId、orderCreateDate 都是索引字段
- 排序规则是业务需求，要支持分页，所以排序要保留
- 当orderCreateDate查询范围在一个月以内时，效率比较好，索引也可用，但查询范围一扩大，就会出现  1/5 基数量索引失效问题
- `先看下此时的执行计划，订单主表进行了全表扫描，sql 执行时间大约 1分钟`

问题分析

通过 sql 诊断发现，表达式

ORDER BY a.customOrderId ASC, a.mainId ASC, a.orderCreateDate DESC

对多个不同条件使用不同方向的排序，将导致无法使用索引。 这是最核心问题。

通过 ChatGPT 优化此 SQL（sql 调优再也没有那么难了）

准备一下，如何向 gpt 发出提问

根据前面的分析，表达式

ORDER BY a.customOrderId ASC, a.mainId ASC, a.orderCreateDate DESC

对多个不同条件使用不同方向的排序，将导致无法使用索引。所以，这将是我们问题的突破口！

稍后提问，我们将采取如下策略：

1. 给 ChatGPT 设定角色：DB、sql 调优专家
2. 描述出我们的问题，把问题突破口告知它
3. 提供出我们的 sql 语句

第一次提问（没解决问题，但是一定要看，并不是 GPT 的错）

（注意：这里我着急，就没有分开设定角色提问，而是一次性提问了，大家可以分开聊天提问也是可以的）

• 开始提问
• GPT 给出的办法如下 从解决方案来看，其实人家说的一点问题没有，问题原因在于我前面提问的时候，没有告诉他，我已经有索引了，并且不能再创建索引了。 所以这次回答虽然没有解决我实际的问题，但是GPT回答问题本身是正确的。 我们也知道了，如何更加准确的提问。

第二次提问（成功解决）

吸取前面的教训，我把索引情况告知 GPT后，它给出了新的回答。 但我还是犯了一个马虎，就是索引没提供全，gpt 还是给出了索引建议。不过无所谓，因为它很聪明，回答的第三点，实际上解决了我的最终问题。而且他给出了完整 sql ，我直接拿这个 sql 实验了一下，

效率提升 将近 8 倍

调整前：500rows retrieved startingfrom1in1 m 13 s 524 ms
调整后：500rows retrieved startingfrom1in8 s 899 ms

虽然，8s 也很慢，但是这是我测试的系统使用极限，实际业务应用中，不会出现这种低效的 sql 组合。 按此优化后，真实使用中，最慢的 2-3s 也出结果了（不要较真，对于这类系统，订单查询这个效率，已经很高了，以前小编的其他项目中，也有要求 200ms 返回结果）

写在最后

人工智能的浪潮已经来袭，这次是 AI 2.0 的时代，抓住先机，你就赢了一半了。 3月份我也没太关注，以为它不会掀起什么大浪，就像

元宇宙

一样，离我们还很远。 但是这次真的不一样，ChatGPT 3.5+ 的来临，很多事情都发生了变化。因为我本身是程序员，我使用最多的就是让他帮我写代码，调 sql 等。而且它写的真的很好，我一个 java8年的程序员，质量跟他都没法比，而且它写的是真快，质量真高！

同时，我近期已经实现的

微信公众号对接 ChatGPT的 python 代码基本上都是用 ChatGPT 写出来的

。开发了三天就在公众号上实现了与 ChatGPT 实时聊天，两天时间公众号分析增加了 230 人。 在大家的试用之下，公众号 ChatGPT 聊天功能现在已经趋于完美。虽然还有优化空间，但是对于个人而言，两三天做到这个效果着实不容易了。

感兴趣的小伙伴，欢迎一起探讨，想体验的也可以过来体验一下，真正的免费开放。
公众号：

javastarboy 

（注意，我微信与公众号都叫 javastarboy ，大家不要进错哦~）