varchar和bigint 关联输出错误

🌞 建议反馈 产品缺陷
1

【 TiDB 使用环境】生产环境 /测试/ Poc
varchar和bigint 关联之后 字段长度超过10多位 就出现关联异常，除了修改表结构和sql转换外，是否有参数可以控制这个现象。

image
image1094×1132 109 KB

2

id =2 的数据是关联异常的数据

3

:joy:能把复现脚本发文字么？对着截图敲一遍太麻烦了~

4

老哥来了

 show CREATE table test.t1 
CREATE TABLE `t1` (
  `id` int(11) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin


INSERT INTO `t1` (`id`, `name`) VALUES (1, '123456789012345611');
INSERT INTO `t1` (`id`, `name`) VALUES (2, '123456789012345612');
INSERT INTO `t1` (`id`, `name`) VALUES (3, '123123');





  show CREATE table test.t2
 CREATE TABLE `t2` (
  `id` int(11) NOT NULL,
  `name` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
 
INSERT INTO `t2` (`id`, `name`) VALUES (1, 123456789012345611);
INSERT INTO `t2` (`id`, `name`) VALUES (2, 123456789012345611);
INSERT INTO `t2` (`id`, `name`) VALUES (3, 123123);


 select t1.*,t2.* from test.t1 ,test.t2 where t1.name =t2.name
5

看执行计划，应该是这里的转换导致的的

image
image1558×391 30.3 KB

6

已经有人提issuess。看上去这里的表现和mysql是一致的。
https://github.com/pingcap/tidb/issues/48860
https://github.com/pingcap/tidb/issues/47792

除了改表结构和手工转换类型以外，没看到有其他更好的解决方案。

7

应该要尽量避免让数据库做隐式转换，用不到索引，效率低下而且容易出现各种各样的问题

8

强制转换。
数据库隐式转换，转换不了时就会报错

9

任何情况下都要避免隐式转换

10

要复线 挺难的

11

通过cast是暂时解决方案，而且要是线上业务SQL肯定不容易改，既然优化器已经给做转换了 那就是说明以上到数据类型差异，只是转换后有丢失，归根结底是产品需要优化改进

12

mysql应该也有这个问题吧，不应该是换tidb才碰到的
MySQL查询精度丢失、varchar与bigint之间隐式类型转换的问题！_mysql varchar转bigint-CSDN博客

13

本来不想说，mysql 不算是tidb的竞品，但某竞品为啥没问题
image

14

:rofl:不难啊，执行楼主的语句就复现出来了。

15

是不是没有做类型转换？

16

你确定没问题，我刚测的mysql8

image
image716×722 143 KB

17

我不是测的mysql

18

issues里明确了，tidb的表现和mysql的表现是一致的。侧面印证了完美支持了mysql的语法 :yum:

19

这种兼容不要也罢

20

:yum:那肯定是取其精华，去其糟粕