MySQL 5.7.19中BIT(64)列的异常行为求助

AI 小北

2026-5-27

嘿，这个问题我之前在MySQL 5.7.x版本踩过坑，正好能给你解释清楚！

问题根源

MySQL 5.7.19对BIT(64)类型的二进制字面量比较存在一个隐式转换的坑：

当你插入短二进制值（比如b'111'）时，MySQL会自动给这个字面量补前导零到64位，和BIT(64)列的存储格式对齐，所以查询能正常匹配；
但当你插入的是64位全1的二进制值时，MySQL在处理查询条件里的b'111...'（64个1）时，会把它当作有符号64位整数来转换——而64位全1的二进制对有符号整数来说是-1，但你存在BIT(64)列里的实际值是无符号的最大值18446744073709551615，两者类型不匹配，自然查不到结果。

可行的解决办法

这里有几个实测有效的方案：

用无符号整数值直接查询
直接使用64位全1对应的无符号整数来匹配：
```
SELECT * FROM test WHERE v = 18446744073709551615;
```
通过HEX函数转换后比较
把列值和二进制字面量都转成十六进制字符串，绕开类型转换的坑：
```
SELECT * FROM test WHERE HEX(v) = HEX(b'1111111111111111111111111111111111111111111111111111111111111111');
```
显式转换为无符号整数
用CAST函数把二进制字面量强制转成无符号64位整数，和列存储的类型对齐：
```
SELECT * FROM test WHERE v = CAST(b'1111111111111111111111111111111111111111111111111111111111111111' AS UNSIGNED);
```