嘿，这个问题其实是TiDB和MySQL在数据类型转换严格性上的差异导致的，我来帮你拆解清楚：

核心原因：sql_mode的默认配置不同 #

TiDB默认开启了严格SQL模式（包含STRICT_TRANS_TABLES），而MySQL 5.7默认可能没有启用这个严格模式。两者对空字符串转INT的处理逻辑不一样：

• 在MySQL 5.7的非严格模式下，空字符串''会被隐式转换成0插入INT字段，不会触发报错
• TiDB的严格模式会把这种隐式转换判定为“数据截断”，直接抛出Data Truncated错误，避免潜在的数据不一致问题

先验证你的TiDB当前sql_mode #

你可以先执行这条SQL查看当前会话的sql_mode配置：

SELECT @@sql_mode;

你会发现TiDB的结果里包含STRICT_TRANS_TABLES，而MySQL 5.7的默认配置里大概率没有这个选项。

解决办法（三种可选，按需选择） #

1. 临时调整会话级别的sql_mode（快速测试用） #

如果只是临时需要兼容MySQL的旧行为，可以在当前会话中关闭严格模式：

SET SESSION sql_mode = 'ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION';

执行完这条命令后，再插入('','aa')就会自动把空字符串转成0插入，不会报错。注意：这个设置只在当前会话生效，断开连接后会恢复TiDB的默认配置。

2. 永久修改全局sql_mode（长期兼容用） #

如果你的业务需要长期保持这种兼容逻辑，可以修改TiDB的配置文件（比如tidb.toml），找到sql-mode配置项，移除STRICT_TRANS_TABLES，然后重启TiDB服务。修改后的配置示例：

sql-mode = "ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION"

3. 代码层面优化（最推荐的方案） #

从数据规范和长期维护的角度，更建议你在代码插入前做逻辑处理：

• 当要插入的INT字段值为空字符串时，主动替换为NULL或者0
• 比如在业务代码里判断，如果输入是''，就转换成NULL再执行插入，这样既兼容TiDB也兼容MySQL，还能避免依赖数据库的隐式转换带来的不确定性

补充小提示 #

TiDB虽然高度兼容MySQL，但在一些数据校验的严格性细节上会有差异，默认开启严格模式是为了帮你提前发现数据类型不匹配的问题，减少后续的脏数据风险。如果不是必须兼容旧代码，建议保持TiDB的默认严格模式，从代码层面优化数据插入的逻辑哦。

内容的提问来源于stack exchange，提问作者chris