使用NOT LIKE条件后SQL返回记录数远超预期的问题排查

你遇到的矛盾核心是：原语句得到的378条并非START表中所有去重COSTCENTER的真实总数，而包含/排除条件的语句是基于真实总数计算的，导致378-84≠577。最可能的原因有以下几点：

1. 字段长度不匹配导致插入时截断去重 #

如果Queue表的COSTCENTER字段长度短于START表的对应字段，插入时过长的COSTCENTER值会被自动截断，原本不同的COSTCENTER被截断后变成相同值，导致原语句插入的去重数量被“压缩”成378。而直接在START表中执行包含/排除条件的SELECT时，是基于完整的COSTCENTER值去重，所以得到的84和577是真实的分类数量，两者相加（661）才是START表实际的去重COSTCENTER总数。

比如START表的COSTCENTER是VARCHAR(15)，存储了0002001234567，而Queue表的COSTCENTER是VARCHAR(10)，插入后会被截断为0002001234，和另一条真实的0002001234重复，最终原语句的去重结果远小于真实值。

2. 数据在原语句执行后发生了变更 #

如果原语句执行完毕后，START表新增了大量含新COSTCENTER的数据，那么后续的包含/排除条件语句是基于更新后的数据集计算的，此时总去重数量已经变为661，和原语句的378没有关联，自然会出现预期和实际不符的情况。

验证与排查步骤 #

• 先确认START表真实的去重COSTCENTER数量：

  SELECT COUNT(DISTINCT COSTCENTER) FROM Dataplace.START;
  

  如果结果是661，说明原语句的插入过程存在数据截断或其他过滤。
• 检查两张表的COSTCENTER字段定义是否一致：

  -- 查看START表字段类型和长度
  DESCRIBE Dataplace.START;
  -- 查看Queue表字段类型和长度
  DESCRIBE Dataplace.Queue;
  

  重点对比COSTCENTER的类型（如VARCHAR/INT）和长度。
• 排查是否存在NULL值干扰：

  SELECT COUNT(DISTINCT COSTCENTER) FROM Dataplace.START WHERE COSTCENTER IS NULL;
  

  NULL值在LIKE条件中会被过滤，但原语句会包含它，不过这无法解释数量反向增长的问题，仅作为补充排查点。

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