明天在测试库上做一个关联查问时呈现了捞出多余的值的状况，当初换个表名重现一下再解释。
如图所示，现有两张表
- user 表，通过 rid 和和 role 表的 id 关联
- role 表，只有 id 和 alias 字段
从图中的数据来看，实践上执行上面的 sql 后应该呈现下图的后果，一个用户对应一个 role，有 1 条数据
SELECT * from rd_user u, rd_role r where u.rid = r.id where r.id = 123456789012345611
然而实际上执行下面的语句却呈现了 2 条数据，如图
一开始我被搞懵了，狐疑是本人对 join 的了解出问题了，百度各种 join 后确定本人的了解没问题。而后又试了好几种分步查问，还是呈现谬误的后果。最初从新查看表构造时发现一个十分坑爹的点，user 表的 rid 数据类型竟然是 varchar，然而 role 的 id 字段是 bigint
本人又新建了两张表试了下，发现用 varchar 和 bigint 关联在个别状况下是没问题的，然而在一直尝试后发现，当这个字段长度大于 16 位时（这个论断不太精确），就会呈现上图的状况。于是把 user 表的 rid 字段改成 bigint 后查问出错的问题就解决了。
按理说到这里就完事了，然而我还是放不下，为啥数据库会出错呢？
于是又查了会儿材料，有了一些小发现。
在一篇文章中，一个博主呈现了另一种状况：
他的是 char 和 int 问题，在执行
select 0 = 'abc'时发现后果是 true
依据他的博文写到 mysql 官网文档说在数字和字符串执行比拟时会主动做转换。
其中，如果 varchar 是 数字 + 字母 的组合，会主动截取后面数字局部，再和数字做比拟。
比方上面这句后果也是 true。
select 1 = '1abc'官网文档地址
MySQL :: MySQL 5.7 Reference Manual :: 12.4.2 Comparison Functions and Operators
Comparison operations result in a value of
1(TRUE),0(FALSE), orNULL. These operations work for both numbers and strings. Strings are automatically converted to numbers and numbers to strings as necessary.比拟运算的后果为 1 (TRUE)、0 (FALSE) 或 NULL。这些操作实用于数字和字符串。必要时，字符串会主动转换为数字，数字会主动转换为字符串。
只看这句的话，官网说的比拟抽象，没说怎么个转换法，也解决不了我的问题。
百度关键词换几轮了没呈现想要的后果，去 bing 上搜寻，有了一个发现。其实那个答复也是来自官网的手册。
MySQL :: MySQL 8.0 Reference Manual :: 12.3 Type Conversion in Expression Evaluation
这一节讲的是进行比拟操作时数据如何做转化
In all other cases, the arguments are compared as floating-point (double-precision) numbers. For example, a comparison of string and numeric operands takes place as a comparison of floating-point numbers.
在所有其余状况下，参数将作为浮点（双精度）数字进行比拟。例如，字符串和数字操作数的比拟是作为浮点数的比拟进行的。
也就是说，在进行 varchar 和 bigint 比拟时，实际上是将它们转成 double 后再比拟的，double 精度失落就算不晓得原理必定也听过了。
既然都查到这里了，我还想晓得到值多大时精度会失落。有趣味的同学能够本人查一下浮点数精度失落，这里贴出要害局部。
计算机中，浮点数由 IEEE 754 规范定下的。IEEE 754 是啥？
百科里这么解释：IEEE 754 规定了四种示意浮点数值的形式：单精确度（32 位）、双精确度（64 位）、延长单精确度（43 比特以上，很少应用）与延长双精确度（79 比特以上，通常以 80 位实现）。
这里取我关怀的，浮点数是 8 字节 64 位，位数如图所示，理论示意位数只有 52 位。
这里有一个在线网站能够计算浮点数
IEEE 754 Calculator (weitz.de)
比方对于整数 5. 换算成二进制是 101(辗转相除法)。计算机会把它换算成第一位是 1，而后是小数点，再前面是尾数的模式，看下图。
这里留神，规范里强制规定第一位是 1。和 52 位尾数凑成了 53 个槽，所以在数值为 2^53 次方处之后的数据都有可能不平安。
咱们做个试验，2 的 53 次方 - 1 的值是 9007199254740991，2 的 53 次方是 9007199254740992，2 的 53 次方 + 1 是 9007199254740993
看下图，9007199254740992 开始，转换成二进制后的位数都是 54 位，因为浮点数最大只能存 53 位，所以最初一位都被舍弃了
9007199254740992 == 9007199254740993 成立
浏览器的管制台上也能够间接输入后果
到这里终于晓得查问出问题的起因了。就是在整数转成二进制后，如果大于 53 位，只有前 53 位值一样，它们之间用 = 号就能返回 true。
这次查资料还得出一个论断，官网文档真的很重要。然而因为母语不是英语的起因，咱们很少会把文档当书看，只有出问题了才想到它。即便平时偶然查阅用了翻译工具，然而翻译来的货色看了后在脑袋里留不下印象，咱们在这方面真的太吃亏了。