【 TiDB 使用环境】生产环境
715
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
只做了一个简单查询
【遇到的问题：问题现象及影响】
使用cast函数查不出结果
表结构发一下
id | bigint(18)
origin_order_id | varchar(100)
把两个sql 的执行计划发一下吧
用能够查出来的那条SQL，把id、origin_order_id 以及转换类型之后的字段值都查出来对比下
id有负数么？看修改记录，为负数的时候有bug
原来是bug
看着有点像，要验证一下，id是不是有负数。
但从时间上看，感觉v7.1.5版本应该修复了才对。
mysql> select cast(id as char(100)) aa from xxxrecord where id=1268107948938424320;
±-------------------+
| aa |
±-------------------+
| 126810794893842432 |
±-------------------+
1 row in set, 1 warning (0.15 sec)
mysql> show warnings;
±--------±-----±-----------------------------------------+
| Level | Code | Message |
±--------±-----±-----------------------------------------+
| Warning | 1406 | Data Too Long, field len 18, data len 19 |
±--------±-----±-----------------------------------------+
1 row in set (0.15 sec)
转化阶段就错 了
升级到753就好了mysql> select cast(id as char(100)) aa,id from xxxxecord where id=1268107948938424320;
±--------------------±--------------------+
| aa | id |
±--------------------±--------------------+
| 1268107948938424320 | 1268107948938424320 |
±--------------------±--------------------+
1 row in set (0.16 sec)
2 个赞
还真是个bug。
感觉7.1版本bug好多，不敢用了，用714，参数不生效，升级到715，cast又失效，表也大量出现err.OperationalError: (8133, 'data inconsistency in table:，最后直接使用753吧
原来是个bug
那这问题就很清楚了
都是打补丁打过来的，我们用的V6.5，现在马上打补丁打到V6.5.10版本了
都转换成bigint类型比较试试呢
都是一个逐渐稳定的过程 可以像楼上说的，改一下cast的类型，不用char试试