如何从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，注意类型声明，就能避开这些隐蔽的陷阱。
相关攻略
电热毯折叠存放后，原则上不建议继续使用，更不可通电加热 先说一个核心判断：折叠存放后的电热毯，最好别再用，更别急着通电。这可不是危言耸听，而是有硬性标准支撑的。根据中国家用电器研究院发布的《电热毯安全使用指南》以及国家强制性标准GB 4706 8-2018的规定，事情是这样的：普通电热毯内部的电热丝
2026励志口号50句精选汇总：穿越周期的精神燃料 口号，常被定义为“供口头呼喊的有纲领性和鼓动作用的简短句子”。但换个角度看，它们更像是浓缩了智慧与行动力的精神燃料，尤其在充满不确定性的时代，一句有力的口号，足以点燃内心的引擎。今天，我们就来盘点一份精选的励志口号集锦，它们历经时间考验，或许能为你
最新励志口号50句精选大盘点：穿透喧嚣的智慧回响 口号，常被定义为“供口头呼喊的有纲领性和鼓动作用的简短句子”。这话没错，但只说对了一半。真正有力量的口号，远不止是呼喊，它更像是一粒思想的种子，能在人心深处扎根，在关键时刻迸发出改变行为的力量。不同气质的口号，自然扮演着不同的角色。今天，我们就来一起
用喜悦添加激情，用喜庆增添勇气，用喜乐调动坚持，用喜气复制毅力，用喜欢追求梦想，用喜笑保持激情 假期归来，如何快速找回工作状态？不妨试试这个配方：用喜悦为你的日常注入激情，用喜庆的氛围为自己增添几分勇气。当坚持变得困难时，想想假期的喜乐，它能帮你调动内心的韧性；而那份过节的喜气，完全可以复制成面对挑
一朝习惯，万事易办 你看，成功的背后，往往站着一个名叫“习惯”的盟友。良好的习惯，正是那份最可靠的保证。 这话一点不假：好习惯能成就一生，而坏习惯，真的可能毁掉一个人的前程。与之相配的，是好方法——好方法让你事半功倍，好习惯则让你受益终身。当习惯与智慧联手，便能创造奇迹；当理想与信心结合，便可换取无
热门专题
热门推荐
要提升HDFS集群的稳定性，这些配置与优化思路值得关注 想让你的Hadoop分布式文件系统（HDFS）集群运行得更稳定、更可靠吗？这既是一项系统工程，也有一套清晰的优化路径——关键在于，你是否在硬件选型、参数配置、运维管理等核心层面都进行了系统性的规划与调优。下面这张图，可以帮助你快速建立起一个关于
HDFS副本策略调整指南 一 核心概念与层级 要玩转HDFS的副本策略，得先理清几个核心概念。它们像齿轮一样层层咬合，共同决定了数据最终落在哪里。 副本因子：这个最好理解，就是一个数据块要存几份。它直接决定了数据的可靠性和存储开销，默认值是3，算是可靠性与成本之间的经典平衡点。 副本放置策略：这是N
HDFS：一个为容错而生的分布式文件系统 在分布式存储领域，数据的安全性与可靠性是系统设计的核心。HDFS（Hadoop分布式文件系统）之所以能成为大数据生态的基石，关键在于其设计了一套多层次、自动化的容错机制。这套机制确保了在硬件故障、网络异常等常见问题发生时，数据依然保持完整且服务持续可用。本文
在HDFS中设置合理权限：一份实战指南 在Hadoop分布式文件系统（HDFS）中，权限管理绝非小事。它直接关系到数据的安全底线和系统的稳定运行。那么，如何为HDFS中的文件和目录设置一套既安全又实用的权限规则呢？下面这份指南，或许能给你带来清晰的思路。 1 基本概念 在动手之前，先得理清几个核心
在Hadoop分布式文件系统（HDFS）中实现数据压缩 处理海量数据时，存储成本与传输效率是两大核心挑战。HDFS提供了多种数据压缩方案，能够有效降低存储空间占用并提升数据处理性能。本文将详细介绍在HDFS中启用和配置数据压缩的几种实用方法。 1 配置文件设置 最直接且全局生效的方式是通过修改Ha