字符串布尔值隐式转整数在Aurora Serverless v1生产环境失效问题

根本原因 #

你遇到的差异本质是MySQL对bit类型的隐式转换规则，以及连接端驱动的处理差异导致的，不属于Aurora或Serverless的独有特性问题（Aurora Serverless v1对MySQL 5.6的bit类型处理和原生MySQL完全一致）：

• bit(1)类型在MySQL中存储的是二进制位值，有效值为二进制的0（对应数值0）和1（对应数值1）
• 当直接用字符串'0'/'1'和bit字段做等值比较时，MySQL会将字符串按ASCII码转换为整数：'0'对应ASCII码十进制48，'1'对应49，和字段实际存储的0、1完全不相等，所以生产环境无返回结果是符合MySQL原生逻辑的。

测试环境正常运行的原因 #

你提到数据库配置无差异，问题出在连接端的驱动/客户端处理逻辑不同：
部分MySQL连接驱动（比如低版本的Connector/J、某些GUI客户端）会自动识别bit类型的查询条件，将传入的字符串格式的'0'/'1'提前转换为数值0/1后再发送给数据库执行，所以你在测试环境看到语句运行正常，实际执行的已经是数值比较的逻辑。
你可以在两个环境分别执行以下语句验证这个差异：

EXPLAIN EXTENDED select * from mytable where IsDeleted = '0';
SHOW WARNINGS;

返回的警告信息里会显示数据库实际执行的SQL语句，测试环境的语句中'0'会被替换为数值0，生产环境则会保留字符串'0'。

修复方案 #

优先选择最规范的数值比较写法，完全规避隐式转换问题：

select * from mytable where IsDeleted = 0;
select * from mytable where IsDeleted = 1;

如果业务逻辑中必须传入字符串格式的条件，可以用以下两种兼容写法：

1. 先将bit字段转为数值再比较：

select * from mytable where CAST(IsDeleted AS UNSIGNED) = '0';
-- 或简写为
select * from mytable where IsDeleted + 0 = '0';

2. 直接匹配二进制位值：

select * from mytable where IsDeleted = b'0';
select * from mytable where IsDeleted = b'1';

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