问题背景

近期由于订单量激增，我们的 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 aLEFT JOIN ordersubinfo b ON a.mainId = b.mainIdLEFT JOIN bizoppinfo bo ON bo.busOppCode = a.busOppCodeAND bo.validStatus = '1'LEFT JOIN orderaftersalesinfo d ON a.id = d.orderId
WHERE 1 = 1AND a.orderCreateDate BETWEEN '2022-12-20 00:00:00' AND '2023-04-27 23:59:59'AND a.returnOrderFlag = '0'AND a.isToKthree NOT IN ('5', '10')AND a.submitFlag = '1'AND a.validStatus = '1'
GROUP BY a.mainId
ORDER BY 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对多个不同条件使用不同方向的排序，将导致无法使用索引。所以，这将是我们问题的突破口！

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

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

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

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

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

第二次提问（成功解决）

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

调整前：500 rows retrieved starting from 1 in 1 m 13 s 524 ms
调整后：500 rows retrieved starting from 1 in 8 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 ，大家不要进错哦~）