为什么尽量避免使用 IN 和 NOT IN?

为什么尽量避免使用 INNOT IN

前言

在SQL查询中,INNOT IN 是常用的关键字,用于筛选符合条件的数据。

然而,尽管它们使用方便,但在某些情况下,使用它们可能会导致效率低下或查询结果不准确。

本文将从效率和潜在问题两个角度,深入探讨为什么应尽量避免使用 INNOT IN,并提供替代方案。

一、效率问题

1. NOT IN 的性能瓶颈

在SQL查询中,NOT IN 往往会导致性能问题,尤其是在处理大数据集时。

以下是一个典型的例子:

假设有两个表 t1t2,每个表都有150万条数据,且 phone 字段上都有索引。

我们想查询 t1phone 不在 t2 中的记录:

SELECT * FROM t1
WHERE phone NOT IN (SELECT phone FROM t2);

这条查询可能会运行得非常慢,甚至需要十几分钟才能完成。

原因是 NOT IN 子查询无法有效利用索引,尤其是在子查询返回的结果集较大时,数据库引擎需要逐条比较,导致性能急剧下降。

2. 使用 NOT EXISTS 优化

相比之下,NOT EXISTS 是一种更高效的替代方案。

同样的查询可以改写为:

SELECT * FROM t1
WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE t1.phone = t2.phone);

这种写法通常只需要20秒左右即可完成查询,性能提升显著。原因是 NOT EXISTS 可以在子查询中利用索引,避免了全表扫描。


二、潜在问题

1. IN 子查询中的列名错误

IN 子查询的一个潜在问题是,如果列名写错,查询可能不会报错,但会返回错误的结果。

例如:

SELECT id1 FROM test1
WHERE id1 IN (SELECT id1 FROM test2);

在这个例子中,test2 表中并没有 id1 列,但查询不会报错,而是返回 test1 中的所有记录。

这是因为 IN 子查询中的列名错误被忽略,导致查询逻辑失效。

2. NOT INNULL 值的问题

NOT IN 在处理包含 NULL 值的数据时,可能会导致查询结果不准确。

例如:

SELECT id1 FROM test1
WHERE id1 NOT IN (SELECT id2 FROM test2);

如果 test2 中的 id2 列包含 NULL 值,查询将不会返回任何结果。

原因是 NULL 值与任何值的比较都会返回 UNKNOWN,导致 NOT IN 条件无法满足。

三、替代方案

为了避免上述问题,可以采用以下替代方案:

1. 使用 EXISTSNOT EXISTS

EXISTSNOT EXISTS 是更安全和高效的替代方案。

例如:

-- 查询存在于 test2 中的 test1 记录
SELECT * FROM test1
WHERE EXISTS (SELECT 1 FROM test2 WHERE test2.id2 = test1.id1);

-- 查询不存在于 test2 中的 test1 记录
SELECT * FROM test1
WHERE NOT EXISTS (SELECT 1 FROM test2 WHERE test2.id2 = test1.id1);

2. 使用 JOIN

JOIN 也可以用来替代 INNOT IN

例如:

-- 查询存在于 test2 中的 test1 记录
SELECT test1.id1
FROM test1
INNER JOIN test2 ON test1.id1 = test2.id2;

-- 查询不存在于 test2 中的 test1 记录
SELECT test1.id1
FROM test1
LEFT JOIN test2 ON test1.id1 = test2.id2
WHERE test2.id2 IS NULL;

四、何时可以使用 INNOT IN

尽管 INNOT IN 存在一些问题,但在某些情况下仍然可以使用。

例如,当查询的条件是一个确定且有限的集合时,IN 是合适的:

SELECT * FROM test1
WHERE id1 IN (1, 2, 3);

这种写法简洁明了,且不会导致性能问题。

五、总结

  • 效率问题NOT IN 在处理大数据集时性能较差,建议使用 NOT EXISTSJOIN 替代。
  • 潜在问题INNOT IN 容易因列名错误或 NULL 值导致查询结果不准确。
  • 替代方案:优先使用 EXISTSNOT EXISTSJOIN,以提高查询效率和准确性。
  • 适用场景:在确定且有限的集合中,INNOT IN 仍然可以使用。

通过合理选择查询方式,可以有效提升SQL查询的性能和可靠性。

– 欢迎点赞、关注、转发、收藏【我码玄黄】,各大平台同名。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 220,458评论 6 513
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 94,030评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 166,879评论 0 358
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,278评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,296评论 6 397
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 52,019评论 1 308
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,633评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,541评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 46,068评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,181评论 3 340
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,318评论 1 352
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,991评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,670评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,183评论 0 23
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,302评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,655评论 3 375
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,327评论 2 358

推荐阅读更多精彩内容