如何从SQL中查询不包含某值的记录_使用NOT IN排除数据
如何从SQL中查询不包含某值的记录：使用NOT IN排除数据
在数据库查询中，想找出“不在某个列表里”的记录，NOT IN似乎是那个最直观的选择。但就是这个看似简单的操作，背后却藏着几个容易踩坑的细节，稍不注意，查询结果就可能变得莫名其妙。
NOT IN 查询结果为空，但明明有不匹配的数据
你有没有遇到过这种情况：用NOT IN筛选数据，结果返回空，可逻辑上明明应该有几条记录才对？这十有八九是NULL值在“暗中作祟”。
在SQL的逻辑世界里，任何值与NULL进行比较（无论是=、!=还是IN/NOT IN），结果都不是简单的真或假，而是会返回一个UNKNOWN（未知）。而WHERE子句只认TRUE，遇到FALSE或UNKNOWN都会把整行数据过滤掉。一旦子查询的结果集里混进了一个NULL，整个NOT IN条件对所有行的判断都可能变成UNKNOWN，最终导致查询结果为空。
- 先检查子查询：比如执行
SELECT user_id FROM orders WHERE status = 'cancelled'，如果其中某条记录的user_id字段恰好是NULL，那么这个子查询结果就会“静默”地破坏掉外层的NOT IN条件。 - 安全的写法是显式排除NULL：
SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders WHERE user_id IS NOT NULL)。在子查询里加上IS NOT NULL的条件，就能从根本上杜绝这个问题。 - 更推荐的做法：其实，直接用
NOT EXISTS来替代NOT IN是更稳妥的选择。它不仅天然对NULL值不敏感，语义上也往往更清晰。
用 NOT EXISTS 替代 NOT IN 更可靠
为什么说NOT EXISTS更可靠呢？它的工作机制和NOT IN有本质不同。NOT EXISTS并不关心具体的值是否相等，它只检查子查询是否能够返回至少一行结果。这种“存在性检查”的逻辑，完美绕开了NULL值比较带来的陷阱。而且，在大多数数据库优化器中，NOT EXISTS的执行计划也往往更稳定、更高效。
- 等价改写示例：将上面的查询改写为
SELECT * FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)。这里的SELECT 1是惯例，意思是只要子查询有结果就行，具体返回什么值并不重要。 - 关键点在于关联条件：务必把关联条件写全（例如
o.user_id = u.id）。如果漏写了，子查询就会变成独立的查询，可能返回结果，导致NOT EXISTS永远为假，或者产生笛卡尔积，引发性能灾难。 - 添加过滤条件：如果想找的是“没有已发货订单的用户”，直接在子查询里加条件即可：
... WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'shipped')。逻辑清晰，不影响外层结构。
NOT IN 在大数据量下性能突然变差
即便解决了NULL的问题，NOT IN在性能上也可能是个“不定时冲击波”。当括号内的子查询结果集变得非常大时，某些数据库引擎（比如MySQL 5.7及更早的版本）可能无法高效地利用索引，查询计划甚至会退化成缓慢的嵌套循环扫描，性能呈断崖式下跌。
- 数据量是分水岭：如果子查询预计会返回成千上万行结果，那么最好一开始就考虑使用
NOT EXISTS，或者LEFT JOIN ... WHERE right_table.id IS NULL的写法。 - 索引是生命线：如果一定要用
NOT IN，请务必确保子查询中用于关联的字段（比如user_id）在目标表上建立了索引。否则，数据库很可能被迫进行全表扫描。 - 避免超长列表：不要把
NOT IN写成字面值列表，比如NOT IN (1,2,3,...,1000)。当列表项超过几百个时，解析和执行效率都会下降。正确的做法是将这些值先存入临时表或使用公共表表达式（CTE），再进行关联查询。
PostgreSQL / SQL Server 中 NOT IN 的额外行为差异
不同的数据库管理系统，在细节处理上总有那么些“个性”。PostgreSQL在NULL处理上严格遵循SQL标准（即遇到NULL则整体条件失效）。而SQL Server在某些兼容模式下，行为可能略有不同。但比这更常见的坑，其实是数据类型不匹配引发的隐式转换。
- SQL Server的隐式转换风险：假设左值是
VARCHAR类型，而右子查询返回的是INT类型，SQL Server可能会尝试将所有左值强制转换为INT。这会导致像'abc'这样的字符串转换失败，进而引发运行时错误。 - PostgreSQL的严格类型检查：相比之下，PostgreSQL要“严格”得多。如果两侧类型不兼容，它会直接报错：
operator does not exist: text = integer，根本不会去尝试隐式转换。 - 统一的解决方案：最稳妥的办法，就是在编写查询时进行显式的类型转换，确保两边类型一致。例如：
id NOT IN (SELECT CAST(user_id AS BIGINT) FROM orders)。
说到底，NULL值和类型匹配这两个问题，在写查询时最容易被人忽略，可一旦出问题，排查起来又相当耗时。养成好习惯，多用NOT EXISTS，注意类型声明，就能避开这些隐蔽的陷阱。
相关攻略
想在《暗黑破坏神4》S11赛季体验独特的“站桩反伤”玩法？这套以“荆棘”为核心的圣骑士构筑将是你的绝佳选择。其核心理念在于转换输出模式：无需频繁追击敌人，而是通过强化自身防御与反弹机制，让攻击者承受巨额伤害。通过精心的装备与技能配置，你的角色将化身为一座移动的尖刺堡垒，任何近身攻击的敌人都将自食其果
在众多铭文搭配方案中，攻击向的“破甲+暴击”组合堪称经典中的经典。破甲效果能直接穿透对手的防御，让每一次攻击都更具威胁。而暴击属性则带来了伤害爆发的可能性，一旦触发便能造成成吨伤害。两者相辅相成，无论是在PVE清怪效率上，还是在PVP对决的瞬间爆发中，都能制造出决定性的优势，让对手防不胜防。 防御型
将Vidu生成的动态视频制作成PPT循环背景，主要方法包括：通过剪辑软件手动拼接首尾一致的视频片段以实现无缝循环；利用Vidu的高级运动参数预设，生成易于衔接的动态视频；或将视频转换为GIF文件直接插入，利用其自动循环特性。此外，网页端展示时可嵌入带循环属性的HTML视频代码，实现流畅播放。
宇树科技冲刺资本市场的步伐，正变得愈发清晰。 5月25日，上交所发布公告，定于6月1日召开上市审核委员会会议，审议宇树科技股份有限公司的首发上市申请。在叩响资本市场大门的同时，宇树在线下渠道的布局上也按下了加速键。 就在5月底，宇树具身智能体验馆的亚洲首店，即将在上海静安久光百货正式亮相。而此前不到
截至4月末，全国5G基站总数突破500万，占移动基站近四成。同期5G移动电话用户达12 62亿户，占比近七成，用户规模持续快速扩张，增长势头在全球通信史上亦属罕见。
热门专题
热门推荐
资金费率是永续合约锚定现货价格的关键机制。当合约价高于现货价时，多头需向空头支付费用；反之则由空头付费。费率每8小时结算，通过经济激励促使价格回归。持续付费通常表明持有多单且市场处于正费率状态。交易者可结合现货持仓与空头合约进行套利，赚取费率收益。
人力资源经理统筹公司人力资源事务，涵盖招聘、培训等多方面职责，其岗位说明书既是企业选人的标准，也是员工履职的指南。借助AI写作工具，可提升说明书撰写效率。
九号公司发布鼹鼠自平衡2 0与同频双闪两项核心技术。前者通过算法与系统协同实现车辆自主平衡，提升低速与驻停时的操控便利与安全；后者基于统一授时与软总线架构，实现多车灯光精准同步，增强车队辨识与协同体验。两项技术体现了九号在底层智能架构上的系统突破，推动两轮出
想要在《毒液突击队》中解锁“难以捉摸”成就？这项挑战对玩家的潜行技巧要求极高，但只要掌握正确方法，成功触发的难度将大大降低。其核心秘诀在于：保持全程隐匿状态，确保没有任何敌人察觉到你的存在。 成就目标解析 “难以捉摸”成就的达成条件非常严格：在指定的任务关卡中，你必须完全避免进入敌人的“警觉”或“发
推荐系统常因语义、多模态和意图理解不足产生偏差。通义千问系列模型可针对性补强：通过轻量模型重排序提升相关性，多模态模型确保图文匹配，指令模型解析用户行为提炼兴趣标签，OCR提取图像文字，并结合PID控制算法动态融合多源信息，依据实时反馈自动优化权重。