关于mysql关联查询,特别慢的坑

from: https://zhuanlan.zhihu.com/p/166629530


最近入职了一个新公司,接收了一个代码写得很烂的项目.花了两天看完代码,来了个需求,需要做一个统计,要做几个表的关联查询,

sql语句非常简单,如下(由于涉密原因,只有最简单的):

clip_image002

查询语句是我手动停止的,查看manifest表数据,猛然发现才不到4万条

clip_image004

第一反应是索引的问题,explain看一下

clip_image006

这个时候大多数人想到的是去加索引,我也不例外.

就在我加索引的过程中,我反应过来一个问题,就这点数据,哪怕是没有索引,也不可能会慢到如此丧心病狂的地步.所以果断排除了索引问题.

查询语句中唯一的判断是"a.bill_no=b.bill_no",那么问题一定出在这里.

查看两个表的编码:

clip_image008clip_image010

好啦,问题一目了然了...

两个字段不同的编码.造成了进行关联查询时,两个字段的判断及其慢.解决方法通常有两种:

1.修改两个表的编码,保持一致.但是这会更改整个表的结构,在不能确定有无其他影响的情况下,建议不要使用.

2.使用转换函数,降编码统一

CONVERT(expr USING transcoding_name)

使用时间立马就有效果

clip_image012

索引生效了

clip_image014

愿意与大家一起踩坑!

posted @   94cool  阅读(997)  评论(0编辑  收藏  举报
编辑推荐:
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
阅读排行:
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 【杭电多校比赛记录】2025“钉耙编程”中国大学生算法设计春季联赛(1)
历史上的今天:
2017-04-12 c# mongo 数组里对象更新
2010-04-12 设置c#windows服务描述及允许服务与桌面交互
2010-04-12 Windows服务“允许服务与桌面交互”的使用和修改方法
2010-04-12 .NET验证码页出错
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5
点击右上角即可分享
微信分享提示