MySQL仅UPDATE时报错“Truncated incorrect INTEGER value”的诡异问题

这个现象其实和MySQL的隐式类型转换逻辑、不同版本的SQL_MODE默认配置差异，以及SELECT/UPDATE语句的执行流程区别密切相关，咱们拆开说：

1. SELECT与UPDATE的执行逻辑差异 #

• 在SELECT语句中，IF(TRUE, 'a', 'b') IS NOT NULL是独立计算的：IF函数返回字符串'a'，IS NOT NULL仅判断该字符串是否为NULL，完全不需要做类型转换，所以不管是IS NULL还是IS NOT NULL都能正常运行。
• 但UPDATE语句的情况不一样：
  • 当你写WHERE IF(...) IS NULL时，条件结果是FALSE，MySQL不会对任何行执行更新操作，自然跳过了后续的类型检查步骤，所以不会报错。
  • 当条件是IS NOT NULL时，结果为TRUE，MySQL需要执行更新（哪怕是col1=col1这种无意义的赋值），这时候执行器的某些内部逻辑会触发隐式类型转换——它尝试把IF函数返回的字符串'a'转换为整数（这个行为属于MySQL未明确标注的细节，甚至可以说是个小bug），而'a'无法被解析为有效整数，于是触发了截断错误。

2. MySQL 5.5 vs 5.7的版本差异 #

这个警告/报错的变化，核心在于默认SQL_MODE的调整：

• MySQL 5.5默认使用宽松模式，SQL_MODE里没有开启严格校验选项，遇到这种隐式类型转换的错误只会触发警告，不会中断语句执行。
• MySQL 5.7默认开启了严格模式（SQL_MODE包含STRICT_TRANS_TABLES等选项），这类类型转换的错误会被直接升级为错误，强制中断语句执行。

验证与解决方法 #

• 验证：在5.7中临时关闭严格模式SET SQL_MODE='';，再运行那条UPDATE语句，你会发现它和5.5一样只出警告，不会报错。
• 解决：要么显式指定表达式类型（比如CAST(IF(TRUE, 'a', 'b') AS CHAR)），要么调整SQL_MODE关闭严格校验（不推荐，严格模式能帮你提前发现潜在问题）。

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