PostgreSQL查询返回不符合ar<=3筛选条件的错误数据是何原因？

ar字段筛选失效的核心原因是该字段为字符类类型（CHAR/VARCHAR/TEXT等），而非数值类型，你写的ar <= '3'触发的是字符串字典序比较，不是数值大小比较。

字符串的比较逻辑是从左到右逐位对比字符的ASCII编码值，某一位比较出大小就直接返回结果，不会继续对比后续位：

• 对比字符串'16'和'3'时，第一位字符分别是'1'（ASCII码49）和'3'（ASCII码51），49 < 51，因此数据库会判定'16' <= '3'的逻辑结果为真，ar值为16的记录自然会被返回。
• 你写的targets <= '3'条件存在同样的风险，如果targets字段也是字符类型存储数值，所有以'0'、'1'、'2'开头的字符串（比如'20'、'100'、'05'）都会被判定为小于'3'，出现不符合预期的返回结果。

• 日期筛选条件的结束值写为'2022-14-06'，公历不存在14月，属于非法日期值。不同数据库对非法日期的兼容逻辑不同，很容易导致日期筛选结果异常，如果你要筛选到2022年6月14日，正确写法应为'2022-06-14'。
• status字段如果是数值类型，你给所有匹配值加了单引号做字符串匹配，虽然多数数据库会做隐式类型转换完成匹配，但一方面可能出现类型转换导致的匹配错误，另一方面会导致status字段上的索引失效，降低大表查询性能。

• 长期最优方案：调整表结构，将ar、targets、status这类存储数值的字段修改为对应数值类型（如TINYINT、INT），后续查询直接写数值比较即可，例如ar <= 3，无需加单引号，从根源上避免类型不匹配导致的筛选错误。
• 临时兼容方案：如果暂时无法修改表结构，查询时对字段做显式数值类型转换再比较，例如MySQL环境下可写为CAST(ar AS SIGNED) <= 3。注意这种写法会导致ar字段上的索引失效，数据量较大时查询性能会明显下降。
• 修正日期条件中的非法日期值，避免日期筛选逻辑异常。

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