tidb null 字段修改默认default失败， Data truncated for column 'varch_test' at row 1

【TiDB 使用环境】测试
【TiDB 版本】7.1.0
【操作系统】centos
【部署方式】自建
复现案例

mysql> show variables like 'sql_mode';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sql_mode      |       |
+---------------+-------+
1 row in set (0.00 sec)

mysql> show create table t3\G
*************************** 1. row ***************************
       Table: t3
Create Table: CREATE TABLE `t3` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  `varch_test` varchar(64) DEFAULT null,
  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */,
  KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

mysql> insert into t3(k,c,pad) select k,c,pad from t3;
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> select * from t3;
+----+---+---+-----+------------+
| id | k | c | pad | varch_test |
+----+---+---+-----+------------+
|  1 | 1 | 1 | 1   | NULL       |
|  2 | 1 | 1 | 1   | NULL       |
|  3 | 1 | 1 | 1   | NULL       |
|  4 | 1 | 1 | 1   | NULL       |
|  5 | 1 | 1 | 1   | NULL       |
|  6 | 1 | 1 | 1   | NULL       |
|  7 | 1 | 1 | 1   | NULL       |
|  8 | 1 | 1 | 1   | NULL       |
+----+---+---+-----+------------+
8 rows in set (0.01 sec)

mysql> alter table t3 modify varch_test varchar(64) not null default "";
ERROR 1265 (01000): Data truncated for column 'varch_test' at row 1

这是符合预期的吧，有null值要先处理null值，然后再改为not null

这一步执行完之后，后插入的四条varch_test不应该是test吗？怎么是NULL

表结构贴错了，是null

测试mysql5.7可以。

image949×893 87.6 KB

select length(varch_test) from t3; 你看下这个字段是空还是字符串

tidb null

image960×911 24.5 KB

感觉是个sql_mode的缺陷

先手工把null值改成空字符串吧

你这个建表语句写错了，‘null’ 可不是null

恩了是的。

image953×371 35.7 KB

你update这一个字段全部改为 null 看看不要加引号

实际修复是按照您说的方法，全部update ''，再alter not null default '';

还好是dev环境，数据量小，如果生产环境，修复就很难了。

生产如果必须搞的话，只能批量搞了。limit 10000 一批批的更新，生产我就搞过

对， 大表就是噩梦了。领导一直问：还多久能修复！！

还好，我是直接拼出来几千或者上万个SQL，用日期，比如时间有索引，加上where条件一天天的更新，放在sql文本里面，然后screen，进入系统命令行，执行，晚上执行，第二天去看结果。就是时间长而已

测试有结论吗

那还好，如果是mysql → DM → tidb 同步架构，业务可能等不起，就算跳过当前ddl，后续修复数据也是大麻烦。

表值null了

挺久的