【 TiDB 使用环境】线上
【 TiDB 版本】5.7.25-TiDB-v6.1.0
【遇到的问题】历史缘由主表外键类型为varchar类型而从表关联键类型为Bigint类型进行连表时，发生了隐式转换，将两个键转换成double类型去匹配，导致精度丢失连到了从表的其他行
【复现路径】
由于业务库保密，自己创建了两个表浮现了场景
CREATE TABLE tmp_t1 (
id bigint(20) NOT NULL,
PRIMARY KEY (id) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_bin ROW_FORMAT = Compact;
INSERT INTO tmp_t1 VALUES (1295772036504131620);
INSERT INTO tmp_t1 VALUES (1295772036504131621);
CREATE TABLE tmp_t2 (
id bigint(20) NOT NULL,
id_f varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL,
PRIMARY KEY (id) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_bin ROW_FORMAT = Compact;
INSERT INTO tmp_t2 VALUES (11, ‘1295772036504131620’);
【问题现象及影响】
【查询语句】
SELECT * from tmp_t2 t2 LEFT JOIN tmp_t1 t1 on t2.id_f = t1.id
【查询结果】
|11|1295772036504131620|1295772036504131620|
|11|1295772036504131620|1295772036504131621|
【个人想法】
我后面强制转换了一手，是可以正常运行的，也知道产生的原因，虽说里面的确是开发过程中的一些不规范导致的，但这个问题我还是想提一下，因为这个语句在Mysql上跑是没有问题的，如果是业务库从Mysql切换到Tidb，而这个问题也不是那么容易发现，推上了生产环境，可能将会导致非常严重的生产事故。Tidb的确在兼容Mysql上做了很多，我也希望Tidb能越来越好，不在这种小问题上损坏口碑，对于不同的公司不同的人不一定能接受的，可能遇到小问题没那么容易排查处理就认为这东西不成熟