昨天（2022-7-22）上线了我的一个功能，测试环境数据量较小，问题不大，但是上生产之后，直接卡死了，然后就开始了这么一次SQL优化，这里记录一下。
不太方便透露公司的表结构，这里我自己建了几张表，模拟一下就可以了。
肯定有杠精要说表可以不这样设计了，但是事实现在系统就是这样设计的，如果想改动表设计，影响面就太大了（我们急着上线哦）。当然，本文的后面也会给出修改设计的方案，以达到更优解。
1. 创建表进货单表：
进货结算单表：
发票表：
发票-结算单关联表：
以上是我自己创建的几张表，先介绍一下这几张表的关系：
进货单表(purchase_order)和进货结算单表(settlement_voucher)通过进货单号(purchase_bill_no)关联。这里值得注意的是： 一个进货单可以对应多个进货结算单，通过purchase_bill_no关联，如以下数据：一个进货结算单可以对应多个进货单，通过purchase_bill_no关联，settlement_voucher表中的purchase_bill_no字段存放多个进货单号，使用英文逗号隔开。如以下数据：发票表(invoice)和结算单表(settlement_voucher)有一个关联关系表(settlement_invoice_relation)发票表和关联关系表使用invoice_code和invoice_number关联结算单表和关联关系表使用settlement_bill_no关联发票和结算单是多对多的关系 2. 需求现在需要以进货结算单表(settlement_voucher)查询出一个列表：
列表字段有【进货时间(多个使用英文逗号隔开)、进货平均单价、进货预定总金额，结算单号，结算平均单价，结算金额，结算时间，发票号码(多个使用英文逗号隔开)，发票代码(多个使用英文逗号隔开)】查询条件有：进货时间(一个进货结算单对应多个进货单时，只要有一个进货单的时间在范围内，就查询到)，结算时间，发票号码(一个结算单对应多个发票时，只要有一个发票能关联上，就查询到)根据结算时间排序当然，实际当时的那个需求，列表字段比这多，查询条件也比这多......
3. 给表插入数据先给货单表(purchase_order)和进货结算单表(settlement_voucher)各自插入10万条数据，我这里使用了存储过程：
调用存储过程生成数据：
生成之后需要随机改几条数据，模拟一个进货单可以对应多个进货结算单，以及一个进货结算单可以对应多个进货单两种情况（这样数据更真实一点）。
一个进货单可以对应多个进货结算单的情况就不模拟了，这种情况其实对这次查询的影响并不大。
一个进货结算单可以对应多个进货单的情况：
再创建一些发票数据和结算单-发票关联数据，需要体现多对多的关系：
4. 开始根据需求写SQL优化第一步，当然是想让产品经理去掉一些查询条件，避免进货单表和进货结算表关联了，但是你懂的。。。。。。
这里就以进货时间为条件查询为例（因为主要就是进货单和进货结算单关联导致慢查询），记得需求哦，就是一个进货结算单可能对应多个进货单，只要有其中一个进货单在时间范围内，就需要查询出这条进货结算单
还有：我上面创建的表中索引也模拟了当时优化之前的索引......
4.1 第一版第一版SQL当时在本地环境执行是用了5秒左右，此时就已经意识到问题了，这别说上生产了，就是在测试环境都得挂掉。
但是看看我在自己的垃圾服务器（双核4G）上跑这条SQL吧，是根本执行不出来的（虽然公司服务器好一些，但是生产环境确实卡死了）：
当时就还没没看执行计划，一眼看去，这个SQL中用到了FIND_IN_SET，肯定是不会走索引的，建了索引也没用，也就是主要是进货单表(purchase_order)和进货结算单表settlement_voucher关联会很慢，毕竟他们是多对多的关系，再加上这恶心的需求。所以现在想想该怎么才能不用 FIND_IN_SET。
对，吃饭期间，突发奇想：我应该可以把进货结算单表拆成一个临时表，如果进货结算单表对应了5个进货单，我就把进货结算单拆成5条数据，这五条数据除了进货单号不一样，其他字段都 一样，这样就可以不用FIND_IN_SET了。
说干就干，于是有了下面第二版SQL。
4.2 第二版向把进货结算单表拆分成上面说的临时表，需要添加一个表：
先来看看怎么把一条进货结算单数据拆分成多条：
来解释一下这个骚操作：
首先我创建了一个只有id的表incre_table，插入了十条数据，并且这十条数据必须是1-10。然后我使用settlement_voucher 右连接了 incre_table，并且只取incre_table中id小于或等于进货单数量的数据。这样就控制了这条SQL应该查询多少条数据（就刚好是一个进货结算单对应的进货单条数）。然后使用SUBSTRING_INDEX去一个一个拆分settlement_voucher表中的进货单号这套SQL执行的结果就是：
综合起来，就写好了第二版SQL：
测试查询数据结果肯定是没有问题的哦！！！
好的，到这里终于把所有用到FIND_IN_SET的地方去掉了，这时看索引就有意义了！
看看执行计划吧：
阿西巴，一堆的全表扫描，看看上面第二版SQL，发现进货表(purchase_order)的purchase_bill_no字段是应该走索引的，按道理这个字段一般设计表的时候就应该已经加索引了，但是我以为只是我以为，它确实没加索引，好的，那就给它加上索引吧：
加完是这个索引后，再看看执行计划：
purchase_order表的purchase_bill_no已经走了索引，但是settlement_invoice_relation咋不走索引，它是有两个索引的。。。。。。
再看看在我的垃圾服务器上执行，看能不能执行出来：
好了，为了让settlement_invoice_relation表的查询也走索引，开始下一轮的SQL优化
4.3 第三版就不在下面去聚合获取invoice_code和invoice_number了，在上面来聚合，至于要以这两个字段作为查询条件，那可以把下面这条SQL再包一层，作为一个临时表再查询一遍，这里就不演示了
再看看执行计划：
这时，基本优化结束，再看看在我的垃圾服务器上跑出的结果：
到这里，基本上生产上是可以在三秒以内查询出来了，本次SQL优化就到此结束了！！！
但是，其实还是可以继续优化的，但是设计到系统改的地方比较多了，影响面比较大，这里就说一下思路，暂时不能实践：
可以把进货单表purchase_order和进货结算单表settlement_voucher之间，建立一个中间表，实现多对多的关系，再加以索引，应该会更快，而且可以一劳永逸，以后这种关联都会比较方便了！
总结到此这篇关于一次SQL优化实战的文章就介绍到这了,更多相关SQL优化实战内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
