数据库查询慢
今天写了个两个关联的sql语句,
1 | select * from a join b on a.relationid=b.id where b.otherid=123 |
a表中的relation跟b表中的id相关联,当运行时数据库的运行速度突然便面了,发现这个语句的运行时间特别的长。
最开始的时候认为查询慢是因为b表中的otherid没有添加索引导致,a表跟b表中的数据量很大,这个连接查询导致全表扫描,后来查看发现otherid是有索引的。
然后发现是a表跟b表中关联的两个字段的数据类型不一样导致在关联的时候大量的数据需要转换数据类型,DBA给出的优化建议是
select * from a where a.relation in(select cast(id nvarcha 50 ) from b where b.otherid=123) 这种建议中根据otherid这个条件能过滤大部分的数据,在把id的类型转换成跟a表中relationid一样,这样一下从原来的查询需要两秒较少的只需要几毫秒。
总结:
1. 数据库在表表关联查询的时候一定要确保关联的字段的数据类型是一样的,因为在表关联的时候如果数据类型不同会进行大量的类型转换,类型的转换是很号时间的操作
2 .在进行数据的查询时候where条件中的语句一定要保持跟条件字段的类型报错一致。避免类型转换
3. 对于复杂的sql语句在优化的时候的一种方法是,可以把具体的逻辑拆分到代码逻辑中而不在数据库中进行大量的计算。例如上面的查询在代码中进行两次查询。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析