MySQL数据库中不同数据类型字段关联后结果居然有这么大差异?

点击上方蓝字关注我

859a29d6c09ad62e7e960e20ee967bc3.png

在数据库的世界里,数据的连接操作是至关重要的。但在处理关联表的字段的数据类型不同时,得到的结果经常会出乎预料。

1.  案例

1.1 数据库中先创建表及数据

-- 创建tb1
CREATE TABLE tb1 (
  id BIGINT NOT NULL PRIMARY KEY, NAME VARCHAR (20)
);




INSERT INTO tb1 (id, NAME)
VALUES
  (1459066134882947196, 'na1'), (1459066134882947172, 'cccb'), (1459066134882947163, 'tttttttn'), (1459066134882947198, 'acqada');
 
--  创建tb2
CREATE TABLE tb2 (
  id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY, pid VARCHAR (20), c1 VARCHAR (10)
);


INSERT INTO tb2 (pid, c1)
VALUES
  ('1459066134882947196', 'cs'), (1459066134882947197, 'tt');

tb1 的id表为bigint,tb2表pid字段类型为varchar

1.2  进行左连接查询

SELECT  a.id,b.pid 
FROM  tb1 a  LEFT JOIN tb2 b 
ON a.id=b.`pid`
WHERE a.id =1459066134882947196

查询结果如下:

ba3fbd71080d9d4e82031253a04579b0.png

结果为非预期,因为2个表的关联字段的内容并不相同

1.3  使用内连接

SELECT  a.id,b.pid 
FROM  tb1 a   JOIN tb2 b 
ON a.id=b.`pid`
WHERE a.id =1459066134882947196

使用内连接后,结果也不正确

364a9e65c2526ce406543d6326de7251.png

1.4  不加where条件的左连接

SELECT  a.id,b.pid 
FROM  tb1 a   LEFT JOIN tb2 b 
ON a.id=b.`pid`

查询结果如下:

fd8149f089363af882b3f2c6fc9fbd08.png

关联后确实是非预期的结果

1.5 不加where条件的内连接

SELECT  a.id,b.pid 
FROM  tb1 a    JOIN tb2 b 
ON a.id=b.`pid`

查询结果为:b6023dd18358457cc23bf95cda36479b.png

此时不加where条件的内连接的结果却是正确的

2. 解决方案

解决此问题的方法主要是解决两个关联字段的类型不同的问题,可以有2种方式

2.1  显式类型转换

在关联的时候显式地进行字段类型转换,例如:

SELECT  a.id,b.pid FROM  tb1 a LEFT JOIN tb2 b 
ON CAST(a.`id`  AS  CHAR)=b.`pid`
WHERE a.id=1459066134882947196

结果如下:661f87fde0d38ef7ea49010d97653094.png

此时结果正确。
内连接结果也正确

SELECT  a.id,b.pid 
FROM  tb1 a    JOIN tb2 b 
ON CAST(a.`id`  AS  CHAR)=b.`pid`
WHERE a.id =1459066134882947196

2.2 改变字段类型(推荐)
如果两张表的数据量较大,使用显式的字段类型转换(包括当前隐式字段类型转换)都将导致关联时不能使用索引,影响性能。因此建议在表设计时就将存在关联关系的字段类型设置为类型相同(字符类型时字符集及排序规则也一致)
例如:

ALTER TABLE  tb2 MODIFY pid BIGINT;

修改后再查询看一下结果:

SELECT  a.id,b.pid 
FROM  tb1 a   LEFT JOIN tb2 b 
ON a.`id`=b.`pid`
WHERE a.id =1459066134882947196

结果正确:

9a588ddf536d6b36326c0116cc424581.png

3. 小结

此情况的出现是因为两表的关联字段类型不同时进行字段类型转换导致。bigint与varchar转换过程中字段精度出现问题,实际超过int最大值的数据(2147483647,即2^31 - 1)的数据被截断为2^31 - 1处理,因为两表进行左关联时,存在异常。

从上面的过程中,也发现左连接过程与内连接的过程中的中间数据结果(1.4及1.5中)也不同。

a1313ae5cfa3d8a0b995e77bf8cbec99.png

往期精彩回顾

1.  MySQL高可用之MHA集群部署

2.  mysql8.0新增用户及加密规则修改的那些事

3.  比hive快10倍的大数据查询利器-- presto

4.  监控利器出鞘:Prometheus+Grafana监控MySQL、Redis数据库

5.  PostgreSQL主从复制--物理复制

6.  MySQL传统点位复制在线转为GTID模式复制

7.  MySQL敏感数据加密及解密

8.  MySQL数据备份及还原(一)

9.  MySQL数据备份及还原(二)

e32d3ba8c8ae1dba26743383880fbb54.png

扫码关注     

dca80c90839aa0030f8bf16306e487ee.jpeg

83bef9c34c8c34e950a67680f63381a1.png

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值