在开发过程中，经常会遇到一些“看起来不合理，但 MySQL 居然能执行成功”的 SQL 问题。最近排查一个 Laravel 查询时，就碰到了这样一个典型案例。

原 SQL：

SELECT
    product_audit_id
FROM
    sourcing_supplier_record_new AS s
WHERE
    s.product_audit_id IN ('1021591020 0')

按正常理解：

'1021591020 0'

应该只是一个字符串。

但实际查询结果却成功返回了：

1021591020

这到底是为什么？

---

问题原因：MySQL 的隐式类型转换

核心原因是：

MySQL 会自动进行类型转换

如果：

• 字段是 INT / BIGINT
• 查询值是字符串

MySQL 会尝试把字符串转成数字再比较。

例如：

SELECT '1021591020 0' + 0;

执行结果：

1021591020

因为 MySQL 在转换数字时：

• 从左往右读取
• 遇到非数字字符停止

于是：

'1021591020 0'

最终被转换成：

1021591020

后面的：

空格 + 0

直接被忽略。

所以这条 SQL：

WHERE product_audit_id IN ('1021591020 0')

实际上等价于：

WHERE product_audit_id IN (1021591020)

因此就能查到数据。

---

这个问题为什么危险？

因为：

SQL 不报错

但结果可能完全错误。

这种隐式转换会导致：

• 数据筛选异常
• 查询结果不准确
• 索引失效
• 排查困难

尤其在：

• Laravel
• Excel 导入
• CSV 数据处理
• API 参数拼接

场景中非常常见。

---

Laravel 中的常见踩坑

错误写法：

whereIn('product_audit_id', ['1021591020 0'])

看似是数组。

但实际上数组里只有：

一个字符串

于是 SQL 最终变成：

IN ('1021591020 0')

导致 MySQL 自动转换。

---

正确写法

如果要查询多个 ID：

whereIn('product_audit_id', ['1021591020', '0'])

或者：

whereIn('product_audit_id', [1021591020, 0])

生成的 SQL：

IN (1021591020, 0)

才是正确的。

---

总结

MySQL 的隐式类型转换虽然“方便”，但也是很多隐藏 Bug 的来源。

像：

IN ('1021591020 0')

这种 SQL，看似错误，MySQL 却依然能执行成功。

开发中如果发现：

• 查询结果异常
• SQL 看起来没问题
• 但返回数据不对

一定要警惕：

MySQL 是否发生了隐式类型转换

这个坑，实际项目里真的非常常见。