查看: 84|回覆: 1

[综合] 隐式转换引起的sql慢查询实战记录

[複製鏈接]

3

主題

0

回帖

0

積分

热心网友

金币
0
閲讀權限
220
精華
0
威望
0
贡献
0
在線時間
0 小時
註冊時間
2011-8-11
發表於 2023-8-21 00:00:00 | 顯示全部樓層 |閲讀模式

引言

实在很无语呀,遇到一个mysql隐式转换问题,问了周边的dba大拿该问题,他们居然反问我,你连这个也不知道?白白跟他们混了那么长   尼玛,我还真不知道。罪过罪过…. 

问题是这样的,一个字段叫task_id, 本身是varchar字符串类型,但是因为老系统时间太长了,我以为是int或者bigint,所以直接在代码写sql跑数据,结果等了好久就是没有反应,感觉要坏事呀。在mysql processlist里看到了该sql语句,直接kill掉。 该字段是有索引的,并且他的sql选择性很高,索引的价值也高。 但为什么这么慢?

分析问题

通过explain分析出了结果,当使用整型来查询字符串的字段会出现无法走索引的情况,看下面可以知道,key为null,没走索引,rows是很大的数值,基本是全表扫描了。  当正常的用字符串查询字符串就很正常了,索引没问题,rows的值为1,这里说的是扫描聚簇索引的rows,而不是索引二级索引。

隐式转换引起的sql慢查询实战记录

那么为什么会出现这问题?

下面是mysql官方给出的说法, 最后一条很重要,当在其他情况下,两个参数都会统一成 float 来比较。 居然新版的mysql在优化器层面已经做了一些调整规避这问题,但我自己的测试版本是mysql 5.6,阿里云用的也是5.7,都没有解决该问题。 看来是更高版本解决吧,这个待验证。

看完了官方解说,我们知道上面那一句慢查询sql,其实就相当于 where to_int(taskid) = 516006380 。当然直接用to_int是显示转换了,但是对比出来的效果是一致的。  不管是隐式转换,还是显示转换,速度能起来才怪。。。 因为mysql不支持函数索引。

# xiaorui.cc
 
if both arguments in a comparison operation are strings, they are compared as strings.
if both arguments are integers, they are compared as integers.
hexadecimal values are treated as binary strings if not compared to a number.
if one of the arguments is a timestamp or datetime column and the other argument is a constant, the constant is converted to a timestamp before the comparison is performed. this is done to be more odbc-friendly. note that this is not done for the arguments to in()! to be safe, always use complete datetime, date, or time strings when doing comparisons. for example, to achieve best results when using between with date or time values, use cast() to explicitly convert the values to the desired data type.
if one of the arguments is a decimal value, comparison depends on the other argument. the arguments are compared as decimal values if the other argument is a decimal or integer value, or as floating-point values if the other argument is a floating-point value.
in all other cases, the arguments are compared as floating-point (real) numbers.

翻译为中文就是:

  • 两个参数至少有一个是 null 时,比较的结果也是 null,例外是使用 <=> 对两个 null 做比较时会返回 1,这两种情况都不需要做类型转换
  • 两个参数都是字符串,会按照字符串来比较,不做类型转换
  • 两个参数都是整数,按照整数来比较,不做类型转换
  • 十六进制的值和非数字做比较时,会被当做二进制串
  • 有一个参数是 timestamp 或 datetime,并且另外一个参数是常量,常量会被转换为 timestamp
  • 有一个参数是 decimal 类型,如果另外一个参数是 decimal 或者整数,会将整数转换为 decimal 后进行比较,如果另外一个参数是浮点数,则会把 decimal 转换为浮点数进行比较
  • 所有其他情况下,两个参数都会被转换为浮点数再进行比较

 

总结

sql查询的时候,字段的类型要保持一致,不然会数据字段的隐式转换,继而出现慢查询。 还是那句废话,多看mysql的慢查询日志,有你想要的.

好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对的支持。

原文链接:http://xiaorui.cc/2018/04/13/记一次隐式转换引起的sql慢查询/

回覆

使用道具 舉報

0

主題

2092

回帖

1萬

積分

琼殿精英

金币
10581
閲讀權限
220
精華
0
威望
0
贡献
0
在線時間
0 小時
註冊時間
2011-10-11
發表於 2026-6-13 08:17:44 | 顯示全部樓層
感谢楼主的分享!

看完这篇帖子真是受益匪浅,之前也遇到过类似的问题,但是没有像楼主分析的这么透彻。楼主的排查思路很清晰,赞一个!
不管是什么数据库,字段类型匹配真的很重要啊

想补充几点个人经验:


  • 我们在开发规范里明确规定了,SQL中的参数类型必须和字段类型一致,发现类型不匹配直接打回重写
  • 其实不只是隐式转换会导致慢查询,像函数运算、LIKE以%开头等也会导致索引失效
  • 建议在测试环境就开启慢查询日志,宁愿在测试环境发现问题,也不要带到生产环境
  • 阿里云RDS有慢查询分析功能,可以自动帮你统计慢SQL,还是挺实用的


另外想问一下楼主,你们后来是怎么处理这个问题的?是修改了代码里的SQL还是对表结构做了调整?如果字段本身确实需要存字符串类型,但是业务上又需要按数字来查询,有没有什么好的方案?

圆梦公社真是越来越热闹了,技术氛围越来越浓!支持楼主多分享这类实战经验~

顶一个!
回覆

使用道具 舉報

您需要登錄後才可以回帖 登錄 | 立即注册

本版積分規則

圆梦公社,专注于为全球华人提供纯粹技术交流的地方,请勿发布任何政治及违法的言论。如有相关侵权、举报、投诉及建议等,请发 E-mail:dzh188@hotmail.com

Powered by Discuz! X5.0 © 2001-2026 Discuz! Team.

在本版发帖返回顶部