
在数据库的世界里,数据的连接操作是至关重要的。但在处理关联表的字段的数据类型不同时,得到的结果经常会出乎预料。
1. 案例
1.1 数据库中先创建表及数据
-- 创建tb1CREATE 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');-- 创建tb2CREATE 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');
1.2 进行左连接查询
SELECT a.id,b.pidFROM tb1 a LEFT JOIN tb2 bON a.id=b.`pid`WHERE a.id =1459066134882947196
查询结果如下:

结果为非预期,因为2个表的关联字段的内容并不相同
1.3 使用内连接
SELECT a.id,b.pidFROM tb1 a JOIN tb2 bON a.id=b.`pid`WHERE a.id =1459066134882947196
使用内连接后,结果也不正确

1.4 不加where条件的左连接
SELECT a.id,b.pidFROM tb1 a LEFT JOIN tb2 bON a.id=b.`pid`
查询结果如下:

关联后确实是非预期的结果
1.5 不加where条件的内连接
SELECT a.id,b.pidFROM tb1 a JOIN tb2 bON a.id=b.`pid`
查询结果为:
此时不加where条件的内连接的结果却是正确的
2. 解决方案
解决此问题的方法主要是解决两个关联字段的类型不同的问题,可以有2种方式
2.1 显式类型转换
在关联的时候显式地进行字段类型转换,例如:
SELECT a.id,b.pid FROM tb1 a LEFT JOIN tb2 bON CAST(a.`id` AS CHAR)=b.`pid`WHERE a.id=1459066134882947196

SELECT a.id,b.pidFROM tb1 a JOIN tb2 bON CAST(a.`id` AS CHAR)=b.`pid`WHERE a.id =1459066134882947196
ALTER TABLE tb2 MODIFY pid BIGINT;SELECT a.id,b.pidFROM tb1 a LEFT JOIN tb2 bON a.`id`=b.`pid`WHERE a.id =1459066134882947196

3. 小结
此情况的出现是因为两表的关联字段类型不同时进行字段类型转换导致。bigint与varchar转换过程中字段精度出现问题,实际超过int最大值的数据(2147483647,即2^31 - 1)的数据被截断为2^31 - 1处理,因为两表进行左关联时,存在异常。
从上面的过程中,也发现左连接过程与内连接的过程中的中间数据结果(1.4及1.5中)也不同。

4. 监控利器出鞘:Prometheus+Grafana监控MySQL、Redis数据库
5. PostgreSQL主从复制--物理复制
6. MySQL传统点位复制在线转为GTID模式复制



原文作者:数据库干货铺;如有侵权,请联系管理员删除。