那些MySQL令人咋舌的隐式转换（完美整理）

最新推荐文章于 2024-09-04 15:19:24 发布

Siwany6691

最新推荐文章于 2024-09-04 15:19:24 发布

阅读量261

点赞数

分类专栏： DATA 文章标签： mysql

本文链接：https://blog.csdn.net/m0_49092973/article/details/107343388

版权

本文探讨了MySQL中一个令人惊讶的隐式类型转换问题，当查询时，数字204027026112927603在比较过程中出现错误匹配。原因是字符串转换为double时可能产生不精确的结果，特别是超过16位数字。为避免这种情况，建议在数据库设计时明确字段类型，避免隐式转换，确保查询的准确性并充分利用索引。

摘要由CSDN通过智能技术生成

一、问题描述

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.00 sec)
 
root@mysqldb 22:19:  [xucl]> select * from t1;
+--------------------+
| id                 |
+--------------------+
| 204027026112927605 |
| 204027026112927603 |
| 2040270261129276   |
| 2040270261129275   |
| 100                |
| 101                |
+--------------------+
6 rows in set (0.00 sec)
奇怪的现象：

root@mysqldb 22:19:  [xucl]> select * from t1 where id=204027026112927603;
+--------------------+
| id                 |
+--------------------+
| 204027026112927605 |
| 204027026112927603 |
+--------------------+
2 rows in set (0.00 sec)

什么鬼，明明查的是204027026112927603，为什么204027026112927605也出来了

二、源码解释
堆栈调用关系如下所示：

640?wx_fmt=jpeg

其中JOIN::exec()是执行的入口，Arg_comparator::compare_real()是进行等值判断的函数，其定义如下

int Arg_comparator::compare_real()
{
  /*
    Fix yet another manifestation of Bug#2338. 'Volatile' will instruct
    gcc to flush double values out of 80-bit Intel FPU r