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

引言

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

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

分析问题

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

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

下面是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的慢查询日志，有你想要的.

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

赞 (0)

相关推荐

  • 深入mysql慢查询设置的详解

    在web开发中,我们经常会写出一些SQL语句,一条糟糕的SQL语句可能让你的整个程序都非常慢,超过10秒一般用户就会选择关闭网页,如何优化SQL语句将那些运行时间 比较长的SQL语句找出呢?MySQL给我们提供了一个很好的功能,那就是慢查询!所谓的慢查询就是通过设置来记录超过一定时间的SQL语句!那么如何应用慢查询呢? 1.开启MySQL的慢查询日志功能默认情况下,MySQL是不会记录超过一定执行时间的SQL语句的.要开启这个功能,我们需要修改MySQL的配置文件,windows下修改my.in

  • mysql慢查询使用详解

    mysql慢查询使用详解

    1 慢查询定义 指mysql记录所有执行超过long_query_time参数设定的时间阈值的SQL语句.慢查询日志就是记录这些sql的日志. 2 开启慢查询日志 找到mysql配置文件my.cnf.在mysqld的下面添加 复制代码 代码如下: log-slow-queries = D:/MySQL/log/mysqld-slow-query.log  #日志存在的位置.(注意权限的问题,可以不用设置,系统会给一个缺省的文件host_name-slow.log) long-query-time

  • 详解MySql的慢查询分析及开启慢查询日志

    我最近也在研究MySQL性能优化的路上,那么今天也算个学习笔记吧! 在小伙伴们开发的项目中,对于MySQL排查问题找出性能瓶颈来说,最容易发现并解决的问题就是MYSQL的慢查询以及没有得用索引的查询. 接下来教大家如何开启MySQL5.0版本以上的慢查询日志记录: OK,一起开始找出mysql中执行起来不"爽"的SQL语句吧. 首先,我们通过mysql命令进入mysql命令行中: [root@yunuo_vm ~]# mysql -u root -p Enter password: W

  • MySQL 开启慢查询日志的方法

    1.1 简介 开启慢查询日志,可以让MySQL记录下查询超过指定时间的语句,通过定位分析性能的瓶颈,才能更好的优化数据库系统的性能. 1.2 登录数据库查看 [root@localhost lib]# mysql –uroot 因为没有设置设置密码,有密码的在 mysql –uroot –p 接密码 1.2.1 进入MySql 查询是否开了慢查询 mysql> show variables like 'slow_query%'; +---------------------+----------

  • MySQL慢查询查找和调优测试

    编辑 my.cnf或者my.ini文件,去除下面这几行代码的注释: 复制代码 代码如下: log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 2 log-queries-not-using-indexes 这将使得慢查询和没有使用索引的查询被记录下来. 这样做之后,对mysql-slow.log文件执行tail -f命令,将能看到其中记录的慢查询和未使用索引的查询. 随便提取一个慢查询,执行explain: 复制代

  • 一次MySQL慢查询导致的故障

    一次MySQL慢查询导致的故障

    我们知道分析MySQL语句查询性能的方法除了使用EXPLAIN 输出执行计划,还可以让MySQL记录下查询超过指定时间的语句,我们将超过指定时间的SQL语句查询称为"慢查询". 一. 起因 研发反应某台数据库僵死,后面的会话要么连接不上,要么要花费大量的时间返回结果,哪怕是一个简单的查询. 二. 处理 首先去监控平台查看服务器以及数据库状态,发现这台数据库有大量的慢查询.继续看服务器监控,CPU 平均使用率较高,IO 读写平均值正常.登录到 MySQL,使用 SHOW PROCESSL

  • MySQL隐式类型的转换陷阱和规则

    前言 相信大家都知道隐式类型转换有无法命中索引的风险,在高并发.大数据量的情况下,命不中索引带来的后果非常严重.将数据库拖死,继而整个系统崩溃,对于大规模系统损失惨重.所以下面通过本文来好好学习下MySQL隐式类型的转换陷阱和规则. 1. 隐式类型转换实例 今天生产库上突然出现MySQL线程数告警,IOPS很高,实例会话里面出现许多类似下面的sql:(修改了相关字段和值) SELECT f_col3_id,f_qq1_id FROM d_dbname.t_tb1 WHERE f_col1_id=

  • MySQL的隐式类型转换整理总结

    前言 前几天在看到一篇文章:价值百万的 MySQL 的隐式类型转换感觉写的很不错,再加上自己之前也对MySQL的隐式转化这边并不是很清楚,所以就顺势整理了一下.希望对大家有所帮助. 当我们对不同类型的值进行比较的时候,为了使得这些数值「可比较」(也可以称为类型的兼容性),MySQL会做一些隐式转化(Implicit type conversion). 比如下面的例子: mysql> SELECT 1+'1'; -> 2 mysql> SELECT CONCAT(2,' test'); -

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

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

    引言 实在很无语呀,遇到一个mysql隐式转换问题,问了周边的dba大拿该问题,他们居然反问我,你连这个也不知道?白白跟他们混了那么长   尼玛,我还真不知道.罪过罪过-. 问题是这样的,一个字段叫task_id, 本身是varchar字符串类型,但是因为老系统时间太长了,我以为是int或者bigint,所以直接在代码写sql跑数据,结果等了好久就是没有反应,感觉要坏事呀.在mysql processlist里看到了该sql语句,直接kill掉. 该字段是有索引的,并且他的sql选择性很高,索引

  • 谈谈MySQL中的隐式转换

    工作过程中会遇到比较多关于隐式转换的案例,隐式转换除了会导致慢查询,还会导致数据不准.本文通过几个生产中遇到的案例来. 基础知识 关于比较运算的原则,MySQL官方文档的描述: https://dev.mysql.com/doc/refman/5.6/en/type-conversion.html 如果 判断符号左右两边有一个为NULL,结果就是null,除非使用安全的等值判断 <=> (none) 05:17:16 >select  null = null; +------------

  • SQL Server 中的数据类型隐式转换问题

    写这篇文章的时候,还真不知道如何取名,也不知道这个该如何将其归类.这个是同事遇到的一个案例,案例比较复杂,这里抽丝剥茧,仅仅构造一个简单的案例来展现一下这个问题.我们先构造测试数据,如下所示: CREATE TABLE TEST ( ID INT, GOOD_TYPE VARCHAR(12), GOOD_WEIGHT NUMERIC(18,2) ) INSERT INTO dbo.TEST VALUES( 1, 'T1',1.27) SELECT GOOD_TYPE, CASE WHEN ( G

  • Mysql 5.6 "隐式转换"导致的索引失效和数据不准确的问题

    Mysql 5.6 "隐式转换"导致的索引失效和数据不准确的问题

    背景 在一次进行SQl查询时,我试着对where条件中vachar类型的字段去掉单引号查询,这个时候发现这条本应该很快的语句竟然很慢.这个varchar字段有一个复合索引.其中的总条数有58989,甚至不加单引号查出来的数据不是我们想要的数据. 使用的是mysql 5.6版本,innoDB引擎 实际情况如下 下面我们来看一下执行的结果 在上面的描述中我们还得注意就是,你的where条件的字符串不加单引号必须是全数字.不然就会报错 还有可能查出来的数据不是我们想要的数据.如下图 分析 从执行结果来

  • 浅谈MySql整型索引和字符串索引失效或隐式转换问题

    目录 问题概述 问题重现 问题引申 结论 问题概述 今天在上班时,DBA突然找出来一段sql,表示该sql存在隐式转换,不走索引.经过我们的查看后,发现是类型varchar的字段, 我们使用条件传入了数值型的值,由于担心违反保密协议,在此就不贴图了,由我重现一下类似情况给大家看一下. 问题重现 首先我们先创建一张用户表test_user,其中USER_ID为了效果我们设置为varchar类型且加上唯一索引. CREATE TABLE test_user ( ID int(11) NOT NULL

  • 解析MySQL隐式转换问题

    解析MySQL隐式转换问题

    一.问题描述 root@mysqldb 22:12: [xucl]> show create table t1\G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` varchar(255) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 1 row in set (0.0

  • MySQL令人大跌眼镜的隐式转换

    MySQL令人大跌眼镜的隐式转换

    目录 MySQL的隐式转换 一.问题描述 二.源码解释 三.结论 MySQL的隐式转换 一.问题描述 show create table t1\G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` varchar(255) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 1

  • MySQL索引失效之隐式转换的问题

    目录 常见索引失效: 一.常见索引失效场景 1.条件字段函数操作 2.条件字段运算操作 3.隐式类型转换 4.隐式字符编码转换 二.类型转换 1.字符串转整型 2.时间类型转换 常见索引失效: 1. 条件索引字段"不干净":函数操作.运算操作 2. 隐式类型转换:字符串转数值:其他类型转换 3. 隐式字符编码转换:按字符编码数据长度大的方向转换,避免数据截取 一.常见索引失效场景 root@test 10:50 > show create table t_num\G ******

  • C语言中自动隐式转换与类型强制转换实例分析

    本文通过一个C程序实例对C语言中自动隐式转换与类型强制转换的注意点进行深入分析,详情如下: 先看一个C程序: #include<stdlib.h> #include<stdio.h> #include<conio.h> double proc(int q){ int n; double sum,t;//本例的关键就在这几个变量的类型上 sum = 2.0; while(sum<=q){ t=sum; //sum = sum+(n+1)/n;//自动隐式转换 sum

  • Java基础之隐式转换vs强制转换

    Java中,经常可以遇到类型转换的场景,从变量的定义到复制.数值变量的计算到方法的参数传递.基类与派生类间的造型等,随处可见类型转换的身影.Java中的类型转换在Java编码中具有重要的作用. 在定义变量时,有许多要注意的问题,一不小心就会出现损失精度或者不兼容类型等问题. 例如: 1.定义长整型数据时,必须加后缀l或L long l =123456789012345L 2.定义单精度类型时(7-8位有效数字),必须加后缀 f 或 F float f = 12.5F 3. boolean类型不可

随机推荐