嘿，这问题我之前排查过类似的，本质是字段类型、常量类型不匹配导致的隐式转换规则差异，再加上表中可能存在的脏数据，最终造成了两条SQL结果不同：

• 先看类型匹配的差异
  你的purchase_depart_id字段是int64（整数类型）：

  • 第一条SQL里的purchase_depart_id = 8，这里的8是整数常量，数据库会直接按整数规则匹配，只挑字段值是整数8的行。
  • 第二条SQL里的purchase_depart_id = '8'，这里的'8'是字符串常量，数据库会触发隐式转换——把int64类型的字段值转成字符串，再和'8'做字符串匹配。

• 脏数据才是关键原因
  第一条结果不符合预期，大概率是你的imspc_inventory_lifecycle_bills_2021表里藏着脏数据：有些行的purchase_depart_id虽然字段定义是int64，但实际存的是字符串形式的'8'（大概率是数据导入时的类型错误搞的鬼）。

  • 用整数8匹配时，这些字符串'8'没法转换成有效整数，会被数据库当成null过滤掉，结果就少了这些行。
  • 用字符串'8'匹配时，数据库会把合法的整数8转成字符串'8'，同时那些脏数据的字符串'8'也能匹配上，所以返回的结果才符合你的预期。

• 给你俩小建议

  1. 先修复表中的脏数据，把字符串形式的'8'转换成整数8，保证数据类型一致性。
  2. 写SQL时尽量让常量类型和字段类型保持一致，别依赖数据库的隐式转换，能少踩很多这种诡异的坑。

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