vlambda博客
学习文章列表

这次数据库优化行为来自于上周五BOSS提了一个数据提取需求，说是想看看中国区门店昨天的订单用来哪些支付方式数据，然后就有了下面这条SQL语句：

SELECT a1.invoiceNo,
       a1.storeNo,
       a1.salesLocalDate,
       a1.salesTime,
       a2.currencyCode,
       a2.tenderCode,
       a1.paymentAmount,
       a3.resultMessage,
       a3.cardNo,
       a1.memberName,
       a5.name
FROM table a1
         inner join table2 a2 on a2.invoiceNo = a1.invoiceNo
         inner join table3 a5 on a5.storeNo = a1.storeNo
         left join tabel4 a3 on a3.invoiceNo = a1.invoiceNo
where a1.companyName = "中国公司名称"
  and a1.salesLocalDate = "2022-03-30"
and (a1.status = 1 or a1.status = 4)

数据库里面最大的表数据为订单产品行大概有600多万条，然后执行这条SQL下来查询获得数据条数1030多条，花了42s，我一看这个性能脸上火辣辣的，这太尴尬了，于是把数据输出给BOSS后，就开始着手优化，可是要优化得进行性能分析，这里我用的数datagrip IDE这个工具我用了两年了，实在太好用了，可以用来管理不同的数据库软件类型，用来做性能测试也是方便，好了，言归正传，我本次sql性能分析手段很简单，我先是把inner join 和 left join 分开运行，很轻松就知道了left join 这个表连接是罪魁祸首，发现了问题，那就应该找方法去解决，当时脑海中第一反应就是在tabel4表中就是加个索引，通过一顿操作后，经过验证效率并没提升，我当时就有点懵逼了，加了索引居然没有提升，对着屏幕发呆了半个小时，然后提起精神检查主表和副表的每个字段，突然一个重大发现出现在眼帘中，震惊了，为什么主表与副表查询条件的这两个字段orderNo字符集不一样？主表的是utf8mb4     而副表的是utf8， 多年的经验告诉我，这就是根本原因所在，马上把t4表的orderNo调整为跟主表orderNo一样的utf8mb4字符集 ，再次执行一次SQL语句，耗时516毫秒

效率提高了几十倍，内心再次腾升小成就。