所以,我正在加入mysql的连接以过滤掉一些不良数据,并且遇到了这个奇怪的问题。
payment_transaction_id
连接。 3463
。 该记录在card_transaction_log中的证明:
select count(*)
from card_transaction_log
where payment_transaction_id = 3463;
>> 1
证明记录正在交易中:
select count(*)
from transaction
where payment_transaction_id = 3463;
>> 1
但是联接不起作用。
select count(*)
from card_transaction_log a, transaction b
where a.payment_transaction_id = b.payment_transaction_id
and a.payment_transaction_id = 3463;
>> 0
老实说,我以前从未在mysql中看到过类似的东西。我什至与我的同事核对,以确保我不会发疯和/或愚蠢。
UPDATE:
虽然与上面相同,但该查询也不起作用:
select count(*)
from card_transaction_log a
join transaction b
on a.payment_transaction_id = b.payment_transaction_id
where a.payment_transaction_id = 3463;
>> 0
payment_transaction_id
是什么类型?我怀疑它不是INT,而是VARCHAR。如果您尝试将VARCHAR与INT进行比较,MySQL会自动将其转换为INT,但可能会发生一些奇怪的事情,例如:]
'3463' = 3463
也是
'3463a' = 3463
但是
'3463a' != '3463b'
请参阅小提琴here。您可以像这样测试您的查询:
select count(*)
from card_transaction_log
where payment_transaction_id = '3463';
而且我怀疑您的查询中至少有一个将返回0。或者您可以强制联接使用整数值:
select count(*)
from card_transaction_log a
join transaction b
on a.payment_transaction_id+0 = b.payment_transaction_id+0
where a.payment_transaction_id = 3463;
您可以尝试:
select count(*)
from card_transaction_log a
join transaction b
on a.payment_transaction_id = b.payment_transaction_id
where a.payment_transaction_id = 5081483008;
我今天也遇到了同样的麻烦,这是我发现的。即使表A上的SQL选择和表B上的SQL选择显示的主键和外键值相等,但这些值实际上是不同的...'\ n',当在其中显示值时,它不会显示一个网格,是我所有外键值的结尾字符...根本原因,我没有注意用于通过“导入”填充表的文件是在互联网上找到的损坏的CSV文件。
您可以进行快速测试,只需手动更新一些预期会加入的外键和主键值,然后再次测试您的查询。如果返回结果,则找到了根本原因!
就我而言,这是由于数据中存在隐藏字符。
我使用以下方法导入了包含电子邮件列表的CSV文件:加载数据文件'c:/temp/users.csv'进入表cloudusers以','结尾的字段封闭在“”'\ n'终止的行忽略0行;
因此,每个VARCHAR的末尾都有一个返回字符。字符串看起来相同,但不是。
当我使用加载数据文件'c:/temp/users.csv'进入表cloudusers以','结尾的字段封闭在“”'\ r \ n'终止的行忽略0行;
生成的VARCHAR随后匹配,并且所有联接都起作用。