文档建议反馈控制台
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么这两个“不在”查询会有不同的结果？

这个问题涉及到数据库查询中的"不在"操作符以及相关的概念和原理。在数据库查询中，"不在"操作符用于判断某个值是否不在指定的集合中。具体来说，这个操作符可以用来判断某个字段的值是否不在一个给定的列表或子查询的结果集中。

当我们执行一个"不在"查询时，查询的结果会根据所使用的操作符和查询条件的不同而有所不同。下面我将详细解释两种常见的"不在"查询情况，并给出相应的答案。

  1. 使用"NOT IN"操作符的"不在"查询： 当我们使用"NOT IN"操作符进行"不在"查询时，查询的结果将包含不在指定列表中的所有值。换句话说，它将返回不满足给定条件的所有记录。这意味着，如果我们使用"NOT IN"操作符查询一个字段的值不在一个给定的列表中，那么结果将包含所有不在该列表中的记录。
  2. 使用"NOT EXISTS"子查询的"不在"查询： 另一种常见的"不在"查询方式是使用"NOT EXISTS"子查询。在这种情况下，我们将一个子查询嵌套在主查询中，并使用"NOT EXISTS"来判断子查询的结果是否为空。如果子查询的结果为空，那么"NOT EXISTS"条件将被满足，从而返回不在子查询结果集中的记录。

综上所述，这两种"不在"查询方式在结果上会有所不同。"NOT IN"操作符将返回不在指定列表中的所有记录，而"NOT EXISTS"子查询将返回不在子查询结果集中的记录。

腾讯云相关产品和产品介绍链接地址：

请注意，以上链接仅供参考，具体的产品选择应根据实际需求和情况进行评估和决策。

相关搜索:OpenCV混合模式实现:为什么看似等价的操作会有不同的结果？不同的结果，为什么？为什么PIL.ImageChops.difference和np.array差异会有不同的结果？为什么post请求会有不同的结果？为什么Spark SQL中嵌套列的查询性能会有所不同？为什么to_sym会有不同的行为？为什么使用线程和使用进程的结果会有所不同？为什么在Application Insights分析中使用这两个查询会得到不同的结果？为什么在JButton中添加ActionListener时，这两个相似的for循环会有不同的结果？为什么在反序列化对象时会有不同的结果？
相关搜索:
页面内容是否对你有帮助？
有帮助
没帮助

相关·内容

EasyGBS云端录像查询结果跟实际的查询结果不同调整方法

近期我们一直在对EasyGBS的云端录像做测试，其中一个重要原因就是广大用户对云端录像的要求不断提高，因此对于云端录像的检查仍然是必不可少的一个环节。...在测试过程中，我们就发现在云端录像的查询结果跟想要查询的结果不同。 原本代码如下： 分析该段代码后我们猜测可能是由于EasyGBS根据通道ID查询结果不唯一，因为通道是自定义的可能会有重复。... = data.rows;         this.total = data.total;       });     }, 但是这样修改代码只能点击搜索一次，之后如果设备ID变了，通道ID不变，查询的数据则不会变...，所以要在watch中监听设备ID，代码如下：  Serial: function() {       this.load();     }, 最后形成预览如下，查询的设备无通道的情况下正常显示无信息

1.5K30

为什么RGB 与 CMYK的差异，会有所不同？

这只是简单的区别。如果您有兴趣了解更多关于为什么这种差异很重要的信息，请继续阅读。 什么是RGB RGB 就是看光 计算机屏幕以不同的红、绿和蓝光组合显示图像、文本和设计中的颜色。...这些子像素根据像素最终显示的颜色以不同的强度点亮，以在黑色监视器上产生结果。 您正在阅读本文的屏幕由数百个像素组成。这些像素聚集在一起以显示您看到的文字和图像。...在 CMYK 模式下将颜色加在一起对结果的影响与 RGB 相反；添加的颜色越多，结果越暗。因此，颜色会被去除或减去，以创造出明亮的效果。...使用黑色时，设计师使用了几种不同的版本，它们不会在您的项目中留下一个洞。 酷黑：60。0 . 0 . 100 暖黑：0。60 . 30 . 100 设计师黑色：70。...RGB 是用于屏幕显示的颜色模式。 在 CMYK 模式下添加的颜色越多，结果越暗。添加到 RGB 的颜色越多，结果越亮。 CMYK 的数值范围为 4x100；RGB 的数值范围为 3x256。

1.6K20

概率统计——为什么条件概率的结果总和直觉不同？

所以另一个孩子也是女孩的概率是1/3。 这个答案的计算过程没什么问题，我想大家应该都能看明白，但是不知道会有多少人觉得奇怪。为什么答案不是 1/2 呢？难道两个孩子的性别不是独立的吗？...我们之前一通分析，用上各种公式进行计算，得到的结果明明是1/3，为什么这里就变成 1/2 了呢？这两道题难道不是一样的吗？...这样理解都行得通，但还是没有解决我们之前的疑惑，为什么看起来完全一样的两件事，得到的结果不同呢？就因为我们看到了其中的一个孩子吗？可是我们看到孩子，与孩子的性别的概率应该无关才对。...我们看孩子之前，两个孩子是一体的，我们看了一眼之后，这两个孩子就区分开来了。我们看之前，这是两个孩子，看了之后，就成了我们看过的孩子和没看过的孩子。从物理学上来看，这两者的熵是不同的。...不论这对夫妻怎么表述，只要他告诉我们一个信息，一个能够将这两个孩子区分开的信息，那么，另一个孩子是男是女都会从条件概率的束缚下脱离出来，恢复自然概率。

1.2K20

「Adobe国际认证」在设计行业,为什么大但的设计,不会有好的结果?

不幸的是，新设计并没有换来用户的喜欢。 当时，Twitter 上充斥着 Snapchat 用户对其最近徽标更新的评论。...用户的满意度是开发者和设计师需要考虑的额外因素，而这一次，事实证明用户满意度很低。 用户背后的原因 这个新LOGO标志没有太多需要分析的地方。所有相同的形状和颜色仍然包括在内。...唯一的区别是轮廓的重量，这绝对是显而易见的。如果 Snapchat 的目的是在用户解锁手机后立即吸引他们的注意力，那么毫无疑问它奏效了。 那么为什么会有如此大的反弹呢？...他们的LOGO标志是熟悉的、怀旧的、安全的——随着改变而来的是那些美好的感觉被抹去，我们必须从头开始。 其次，新LOGO标志在游戏中扮演着重要角色“其中一个与另一个不同”。...最流行的平面设计趋势之一是设计中的极简主义。人们正在删除诸如轮廓和额外装饰之类的元素，并满足于减少。简约的设计与压倒性的相反：它们易于理解且易于使用。

28320

明明结果是对的，为什么被合并查询后得到的结果却出错了？| Power Query躲坑

最近，有位朋友在一个实际工作问题中，在表2使用合并查询从表1的结果中匹配最高（阶段）项，眼看着表1的结果是对的，但表2里却得到了错误的返回结果，具体情况如图所示： 为什么会这样？...我们先来看表1的处理情况。 为了合并查询得到最高阶段项，对表1进行降序排序： 然后通过删除重复项保留最高阶段数据： 从表1的结果来看，的确保留了最高阶段的数据。...然后，在表2里使用合并查询获取表1中的结果并展开： 咦！！！ 表1的处理结果明明是阶段4（报价），为什么合并查询得到的结果却是阶段2（售前）？ 这难道是Power Query的Bug吗？...实际上，经过这么多年的发展，Power Query已经相当成熟了，合并查询这种基本的功能，不大可能存在这样的Bug或低级错误的。...但是，因为是跨查询引用，而且从表面上看，被引用的查询结果显示上并没有错误，从而使得错误被隐藏得相对较深一些（本案例处理步骤较少，发现相对容易，如果步骤更多一些，可能发现起来就更难一些）。

2.5K10

MySQL 页完全指南——浅入深出页的原理

那 InnoDB 为什么要这么设计？假设我们没有页这个概念，那么当我们查询时，成千上万的数据要如何做到快速的查询出结果？...有了 Infimum Record 和 Supremum Record ，现在查询不需要将某一页的 User Records 全部遍历完，只需要将这两个记录和待查询的目标记录进行比较。...比如我要查询的数据 id = 101 ，那很明显不在当前页。接下来就可以通过下一页指针跳到下页进行检索。...至于为什么是粗略，毕竟 Page Directory 中不是完整的数据，二分查找出来的结果只能是个大概的位置，找到了这个大概的位置之后，还需要回到 User Records 中继续的进行挨个遍历匹配。...里面有个两个参数可能会有点混淆，分别是PAGE_N_HEAP和PAGE_N_RECS ，都是当前 User Records 中记录的数量，唯一的不同在于，PAGE_N_HEAP 中是包含了被标记为删除的记录的

26230

MySQL 页完全指南——浅入深出页的原理

上图中的 User Records 的区域就是用来存储行数据的。那 InnoDB 为什么要这么设计？假设我们没有页这个概念，那么当我们查询时，成千上万的数据要如何做到快速的查询出结果？...有了 Infimum Record 和 Supremum Record ，现在查询不需要将某一页的 User Records 全部遍历完，只需要将这两个记录和待查询的目标记录进行比较。...比如我要查询的数据 id = 101 ，那很明显不在当前页。接下来就可以通过下一页指针跳到下页进行检索。...至于为什么是粗略，毕竟 Page Directory 中不是完整的数据，二分查找出来的结果只能是个大概的位置，找到了这个大概的位置之后，还需要回到 User Records 中继续的进行挨个遍历匹配。...里面有个两个参数可能会有点混淆，分别是PAGE_N_HEAP和PAGE_N_RECS ，都是当前 User Records 中记录的数量，唯一的不同在于，PAGE_N_HEAP 中是包含了被标记为删除的记录的

68120

一个2高1弹的核酸检测系统，如果是我会这样设计

支持弹性伸缩：查询核酸结果的时间并不均匀，会存在流量热点，系统的能力要能水涨船高，流量越多，系统的处理能力也越强。国家资源能节省还是要节省的。...toC端系统的用户是查询核酸天数的公民。 toB端系统的用户是核酸检测点的手机和对检测结果进行分析的组织。 进行这样拆分的着眼点是对弹性伸缩的诉求不同。...两个系统面向的用户不同，提供的能力不同，qps不同，对系统能力水平扩展的诉求不同。 核酸检测点和核酸检测组织使用的系统，为什么不进行拆分。qps虽差别，但在同一个量级。...核酸检测点的数量与每天检查核酸状态的数量相比，不在一个量级。从2高一弹的视角看，这两个可一起变化。 在业务上看这两个耦合度更高，两者配合才能完成一次核酸状态测定。...因为核酸的检测结果，并不要求实时更新。 查询核酸状态和更新核酸状态，是两件事，不需要耦合在一起。将这两个操作放在不同的上下文中，由模块来承载，在扩展性上更好。

26250

面试官：为什么mysql不建议执行超过3表以上的多表关联查询？

但实际业务中一般不会有这么蠢的行为，一般关联会有连接条件，并且连接条件上会有索引，一般是有一个结果集比较小，拿到这个结果集去另一张表去关联出其它信息，如果放到service层去做，最快的方式是，先查A表...但是确实大多数业务都会考虑把这种合并操作放到service层，一般是有以下几方面考虑： 第一：单机数据库计算资源很贵，数据库同时要服务写和读，都需要消耗CPU，为了能让数据库的吞吐变得更高，而业务又不在乎那几百微妙到毫秒级的延时差距...举一个很常见的业务例子，在分库分表中，要同步更新两个表，这两个表位于不同的物理库中，为了保证数据一致性，一种做法是通过分布式事务中间件将两个更新操作放到一个事务中，但这样的操作一般要加全局锁，性能很捉急...原本一条查询，这里却变成了多条查询，返回结果又是一模一样。 事实上，用分解关联查询的方式重构查询具有如下优势： 让缓存的效率更高。 许多应用程序可以方便地缓存单表查询对应的结果对象。...将查询分解后，执行单个查询可以减少锁的竞争。 在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展。 查询本身效率也可能会有所提升 可以减少冗余记录的查询。

7.6K00

Mybatis二级缓存_redis二级缓存

，并且将查询结果放到缓存中。...---- 四、避免使用二级缓存 可能会有很多人不理解这里，二级缓存带来的好处远远比不上他所隐藏的危害。 缓存是以namespace为单位的，不同namespace下的操作互不影响。...为什么避免使用二级缓存 在符合【Cache使用时的注意事项】的要求时，并没有什么危害。 其他情况就会有很多危害了。 针对一个表的某些操作不在他独立的namespace下进行。...如果在UserMapper.xml中做了刷新缓存的操作，在XXXMapper.xml中缓存仍然有效，如果有针对user的单表查询，使用缓存的结果可能会不正确。...但是你也许想到了一种常见的情况。 多表操作一定不能使用缓存 为什么不能？ 首先不管多表操作写到那个namespace下，都会存在某个表不在这个namespace下的情况。

37320

mybatis的二级缓存_mybatis注解详解

，并且将查询结果放到缓存中。...---- 四、避免使用二级缓存 可能会有很多人不理解这里，二级缓存带来的好处远远比不上他所隐藏的危害。 缓存是以namespace为单位的，不同namespace下的操作互不影响。...为什么避免使用二级缓存 在符合【Cache使用时的注意事项】的要求时，并没有什么危害。 其他情况就会有很多危害了。 针对一个表的某些操作不在他独立的namespace下进行。...如果在UserMapper.xml中做了刷新缓存的操作，在XXXMapper.xml中缓存仍然有效，如果有针对user的单表查询，使用缓存的结果可能会不正确。...但是你也许想到了一种常见的情况。 多表操作一定不能使用缓存 为什么不能？ 首先不管多表操作写到那个namespace下，都会存在某个表不在这个namespace下的情况。

32010

从零开始带你成为MySQL实战优化高手学习笔记（一）

如果只考虑一个查询任务，系统建立一个链接，查询完毕处理结果，然后释放链接，完事了。 假如有多个线程都要对数据库进行操作，怎么办？处理完一个之后再处理下一个？...数据库的设计师们做了一系列的东西来保证这个。 1、缓冲池 为什么要有缓冲池？因为快，缓冲池在内存中，数据库最终存储在磁盘中，对磁盘进行增删改查和对内存进行增删改查肯定不在一个级别。...关于锁的知识，后面也会有。 2、undo日志 搞个图，这两个图都是InnoDB架构图，包含很多东西，先不讲，了解一下。 还是上面那个更新，更新失败，肯定要回滚，要不然数据不一致就产生错误了？...设为2，会把redo日志刷入系统的cache缓存中，每隔一段时间MySQL再主动将系统Cache中的数据批量同步到磁盘。这种情况就和0差不多了。 这三种策略选哪一种还需要根据不同情况做取舍。...MySQL会有一个后台IO线程，会在之后随机把内存中的buffer pool中修改的数据刷回磁盘。

78720

【MySQL】MySQL中MVCC多版本并发控制的概念

注意，在 READ UNCOMMITTED 和 SERIALIZABLE 这两个级别中，一个是不走事务，一个是串行化的执行事务，它们都是执行的 当前读 。...因此，MVCC 的场景就是在 READ COMMITTED 和 REPEATABLE READ 这两个事务隔离级别中。...和 low_limit_id 之间，就需要判断 DB_TRX_ID 在不在 trx_ids 列表中（ 4.1 在，说明创建 ReadView 时这个记录上的事务还活跃的，这个版本不能被访问 4.2 不在...最后一点则是事务隔离机制的不同，对于 MVCC 的影响也有不同。之前我们说过 REPEATABLE READ 是能防止 幻读 情况发生的。为什么能防止呢？...，但是，最后查询到的结果没有发生变化，还是和第一次查询的结果是一样。

12010

GROUP BY 后 SELECT 列的限制：which is not functionally dependent on columns in GROUP BY clause

GROUP BY 之后不能直接引用原表（不在 GROUP BY 子句）中的列 ？...为什么会有 ONLY_FULL_GROUP_BY 模式 　　虽然案例中，无论是“严格模式”，还是“宽松模式”，结果都是对的，那是因为 cno 与 cname 唯一对应的，如果 cno 与 cname 不是唯一对应...通过上图，相信大家也都能看到，这里不做更深入的讲解了，有兴趣的可以去查相关资料。 为什么聚合后不能再引用原表中的列 　　很多人都知道聚合查询的限制，但是很少有人能正确地理解为什么会有这样的约束。...a ≠ {a} 　　这两个层级的区别分别对应着 SQL 中的 WHERE 子句和 HAVING 子句的区别。...总结 　　1、SQL 严格区分层级，包括谓词逻辑中的层级（EXISTS），也包括集合论中的层级（GROUP BY）； 　　2、有了层级区分，那么适用于个体上的属性就不适用于团体了，这也就是为什么聚合查询的

3K50

为什么阿里巴巴规定禁止超过三张表 join？

但实际业务中一般不会有这么蠢的行为，一般关联会有连接条件，并且连接条件上会有索引，一般是有一个结果集比较小，拿到这个结果集去另一张表去关联出其它信息。...如果放到service层去做，最快的方式是，先查A表，得到一个小的结果集，一次rpc，再根据结果集，拼凑出B表的查询条件，去B表查到一个结果集，再一次rpc，再把结果集拉回service层，再一次rpc...举一个很常见的业务例子，在分库分表中，要同步更新两个表，这两个表位于不同的物理库中，为了保证数据一致性，一种做法是通过分布式事务中间件将两个更新操作放到一个事务中，但这样的操作一般要加全局锁，性能很捉急...原本一条查询，这里却变成了多条查询，返回结果又是一模一样。 事实上，用分解关联查询的方式重构查询具有如下优势： 让缓存的效率更高。 许多应用程序可以方便地缓存单表查询对应的结果对象。...将查询分解后，执行单个查询可以减少锁的竞争。 在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展。 查询本身效率也可能会有所提升 可以减少冗余记录的查询。

1.1K10

神奇的 SQL 之层级 → 为什么 GROUP BY 之后不能直接引用原表中的列

为什么 GROUP BY 之后不能直接引用原表（不在 GROUP BY 子句）中的列 ？ 莫急，我们慢慢往下看。...那为什么会有 ONLY_FULL_GROUP_BY 模式呢 ？ 我们继续往下看 阶 　　阶（order）是用来区分集合或谓词的阶数的概念。谓词逻辑中，根据输入值的阶数对谓词进行分类。...通过上图，相信大家也都能看到，这里不做更深入的讲解了，有兴趣的可以去查相关资料。 为什么聚合后不能再引用原表中的列 　　很多人都知道聚合查询的限制，但是很少有人能正确地理解为什么会有这样的约束。...a ≠ {a} 　　这两个层级的区别分别对应着 SQL 中的 WHERE 子句和 HAVING 子句的区别。...总结 　　1、SQL 严格区分层级，包括谓词逻辑中的层级（EXISTS），也包括集合论中的层级（GROUP BY）； 　　2、有了层级区分，那么适用于个体上的属性就不适用于团体了，这也就是为什么聚合查询的

2.1K20

为什么 GROUP BY 之后不能直接引用原表中的列

为什么 GROUP BY 之后不能直接引用原表（不在 GROUP BY 子句）中的列 ？ 莫急，我们慢慢往下看。...那为什么会有 ONLY_FULL_GROUP_BY 模式呢 ？ 我们继续往下看 阶 　　阶（order）是用来区分集合或谓词的阶数的概念。谓词逻辑中，根据输入值的阶数对谓词进行分类。...通过上图，相信大家也都能看到，这里不做更深入的讲解了，有兴趣的可以去查相关资料。 为什么聚合后不能再引用原表中的列 　　很多人都知道聚合查询的限制，但是很少有人能正确地理解为什么会有这样的约束。...a ≠ {a} 　　这两个层级的区别分别对应着 SQL 中的 WHERE 子句和 HAVING 子句的区别。...总结 　　1、SQL 严格区分层级，包括谓词逻辑中的层级（EXISTS），也包括集合论中的层级（GROUP BY）； 　　2、有了层级区分，那么适用于个体上的属性就不适用于团体了，这也就是为什么聚合查询的

1.7K10

面试前必须知道的MySQL命令【expalin】

前言 只有光头才能变强 刷面试题的时候，不知道你们有没有见过MySQL这两个命令：explain和profile(反正我就见过了).. 之前虽然知道这两个命令大概什么意思，但一直没有去做笔记。...1.2为什么需要explain命令 我们很多时候编写完一条SQL语句，往往想知道这条SQL语句执行是否高效。...在id列上也会有几种情况： 如果id相同执行顺序由上至下。 如果id不相同，id的序号会递增，id值越大优先级越高，越先被执行。 (一般有子查询的SQL语句id就会不同) ?...中的第二个或者随后的查询，其次取决于外面的查询 UNION RESULT：UNION 的结果 SUBQUERY：子查询中的第一个select语句(该子查询不在from子句中) DEPENDENT SUBQUERY...Using temporary：在查询结果排序时会使用一个临时表，一般出现于排序、分组和多表 join 的情况，查询效率不高，建议优化。

98320

Java 理论概念·BloomFilter 判断元素存在

查询某个变量的时候我们只要看看这些点是不是都是 1，就可以大概率知道集合中有没有它了，如果这些点有任何一个 0，则被查询变量一定不在；如果都是 1，则被查询变量很可能在。...这就是布隆过滤器的基本思想。 简而言之，如果检测结果都为 1，该元素不一定在集合中；但如果检测结果存在 0，该元素一定不在集合中。...当我们需要判断 “ziyou” 字符串是否存在的时候只要在一次对字符串进行映射函数的操作，得到四个 1 就说明 “ziyou” 是可能存在的。 为什么说是可能存在，而不是一定存在呢？...结论 所以通过上面的例子我们就可以明确： 一个元素如果判断结果为存在的时候元素不一定存在，但是判断结果为不存在的时候则一定不存在。 布隆过滤器可以添加元素，但是不能删除元素。...黑白名单存储 工作中经常会有一个特性针对不同的设备或者用户有不同的处理方式，这个时候可能会有白名单或者黑名单存在，所以根据 BloomFilter 过滤器的特性，我们也可以用它来存在这些数据，虽然有一定的误算率

46220

Mybatis二级缓存，你确定要用么？

2）查询时要求的结果集中的结果范围。 3）这次查询所产生的最终要传递给JDBC java.sql.Preparedstatement的Sql语句字符串（boundSql.getSql() ）。...三、避免使用二级缓存 可能会有很多人不理解这里，二级缓存带来的好处远远比不上他所隐藏的危害。 缓存是以namespace为单位的，不同namespace下的操作互不影响。...在符合【Cache使用时的注意事项】的要求时，并没有什么危害。 其他情况就会有很多危害了。 针对一个表的某些操作不在他独立的namespace下进行。...如果在UserMapper.xml中做了刷新缓存的操作，在XXXMapper.xml中缓存仍然有效，如果有针对user的单表查询，使用缓存的结果可能会不正确。...但是你也许想到了一种常见的情况。 多表操作一定不能使用缓存 为什么不能？ 首先不管多表操作写到那个namespace下，都会存在某个表不在这个namespace下的情况。

4.3K72
点击加载更多

扫码

添加站长 进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

更多标签

活动推荐

    运营活动

    活动名称
    广告关闭

    腾讯云开发者

    扫码关注腾讯云开发者

    扫码关注腾讯云开发者

    领取腾讯云代金券

    热门产品

    热门推荐

    更多推荐

    Copyright © 2013 - 2024 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有

    深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569

    腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287

    领券