简体   繁体   English

mysql查询SELECT x WHERE xy NOT IN(子查询)不起作用

[英]mysql query SELECT x WHERE x.y NOT IN (SUBQUERY) not working

mysql> WITH 2 extra rows(86321 and 28034) in profile_zipcodes,why is my third query NOT finding them? mysql> profile_zipcodes中有2个额外的行(86321和28034),为什么我的第三个查询找不到它们?

SELECT zipcode from profile_zipcodes;
+---------+
| zipcode |
+---------+
| 01971   |
| 02110   |
| 02119   |
| 02124   |
| 02180   |
| 07086   |
| 07087   |
| 10008   |
| 10019   |
| 10021   |
| 10022   |
| 10024   |
| 10025   |
| 10095   |
| 10098   |
| 10099   |
| 10110   |
| 10112   |
| 10118   |
| 10131   |
| 10152   |
| 10157   |
| 10158   |
| 10159   |
| 10160   |
| 10161   |
| 10162   |
| 10166   |
| 10174   |
| 28034   |
| 33306   |
| 33319   |
| 50301   |
| 62334   |
| 63031   |
| 63131   |
| 63138   |
| 63141   |
| 63366   |
| 63376   |
| 67002   |
| 86321   |
+---------+
42 rows in set

mysql> mysql>

SELECT DISTINCT zip FROM profile_stats;
+-------+
| zip   |
+-------+
| NULL  |
| 01971 |
| 02110 |
| 02124 |
| 02180 |
| 07086 |
| 07087 |
| 10008 |
| 10019 |
| 10021 |
| 10022 |
| 10024 |
| 10025 |
| 10095 |
| 10098 |
| 10099 |
| 10110 |
| 10112 |
| 10118 |
| 10131 |
| 10152 |
| 10157 |
| 10158 |
| 10159 |
| 10160 |
| 10161 |
| 10162 |
| 10166 |
| 10174 |
| 33306 |
| 33319 |
| 50301 |
| 62334 |
| 63031 |
| 63131 |
| 63138 |
| 63141 |
| 63366 |
| 63376 |
| 67002 |
+-------+
40 rows in set (0.00 sec)

mysql> mysql>

SELECT * FROM profile_zipcodes WHERE profile_zipcodes.zipcode NOT IN 
(SELECT DISTINCT zip FROM profile_stats);
Empty set (0.00 sec)

My php code actually runs this query: 我的PHP代码实际上运行此查询:

DELETE FROM profile_zipcodes WHERE profile_zipcodes.zipcode NOT IN (SELECT DISTINCT zip FROM profile_stats)

Whenever a user changes their zip code or deletes their profile, and it was working fine, then suddenly I started noticing that zip codes with no profiles attached were remaining in the dynamically updated pull down box and debugging showed the query was still being run but the old zips were remaining and testing showed that an identically worded SELECT wasn't finding the orphan zips - it did work for a while, then it stopped? 每当用户更改邮政编码或删除其个人资料时,它运行正常,然后突然我开始注意到没有附加个人资料的邮政编码保留在动态更新的下拉框中,并且调试显示查询仍在运行,但是仍然保留了旧的拉链,并且测试表明,措辞相同的SELECT找不到孤立的拉链-它确实工作了一段时间,然后停止了?

Your profile_stats table contains a NULL value on the zip column, while this query that makes use of IN clause will work as expected: 您的profile_stats表的zip列上包含NULL值,而使用IN子句的此查询将按预期工作:

DELETE FROM profile_zipcodes
WHERE
  profile_zipcodes.zipcode IN (SELECT DISTINCT zip FROM profile_stats)

using NOT IN can be a little tricky (please see this question , it's about SQL Sever but the problem is the same). 使用NOT IN可能会有些棘手(请参阅此问题 ,它与SQL Sever有关,但问题是相同的)。

You can try with this: 您可以尝试以下操作:

DELETE FROM profile_zipcodes
WHERE
  profile_zipcodes.zipcode NOT IN (SELECT DISTINCT zip
                                   FROM profile_stats
                                   WHERE zip IS NOT NULL)

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM