怎么正确使用PostgreSQL中的OR
发表于:2026-10-31 作者:千家信息网编辑
千家信息网最后更新 2026年10月31日,本篇内容介绍了"怎么正确使用PostgreSQL中的OR"的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成
千家信息网最后更新 2026年10月31日怎么正确使用PostgreSQL中的OR
本篇内容介绍了"怎么正确使用PostgreSQL中的OR"的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
在SQL语句中,对OR使用不当可能会导致较差的查询效率。这并不意味着不能用OR而是在使用OR时需考虑可能存在的性能问题。
测试数据:
DROP TABLE a;CREATE TABLE a(id integer NOT NULL, a_val text NOT NULL);INSERT INTO a SELECT i, md5(i::text) FROM generate_series(1, 1000000) i;DROP TABLE b; CREATE TABLE b(id integer NOT NULL, b_val text NOT NULL);INSERT INTO b SELECT i, md5(i::text) FROM generate_series(1, 1000000) i;ALTER TABLE a ADD PRIMARY KEY (id);ALTER TABLE b ADD PRIMARY KEY (id);ALTER TABLE b ADD FOREIGN KEY (id) REFERENCES a;VACUUM (ANALYZE) a;VACUUM (ANALYZE) b;
OR vs IN
条件语句p1 OR p2,如可以考虑使用IN来改写,比如:
[local:/data/pg12]:5432 pg12@testdb=# EXPLAIN verboseSELECT id FROM aWHERE id = 42 OR id = 4711; QUERY PLAN --------------------------------------------------------------------------- Bitmap Heap Scan on public.a (cost=8.87..16.80 rows=2 width=4) Output: id Recheck Cond: ((a.id = 42) OR (a.id = 4711)) -> BitmapOr (cost=8.87..8.87 rows=2 width=0) -> Bitmap Index Scan on a_pkey (cost=0.00..4.43 rows=1 width=0) Index Cond: (a.id = 42) -> Bitmap Index Scan on a_pkey (cost=0.00..4.43 rows=1 width=0) Index Cond: (a.id = 4711)(8 rows)[local:/data/pg12]:5432 pg12@testdb=# [local:/data/pg12]:5432 pg12@testdb=# EXPLAIN verboseSELECT id FROM aWHERE id in (42,4711); QUERY PLAN ---------------------------------------------------------------------------- Index Only Scan using a_pkey on public.a (cost=0.42..8.88 rows=2 width=4) Output: id Index Cond: (a.id = ANY ('{42,4711}'::integer[]))(3 rows)[local:/data/pg12]:5432 pg12@testdb=#使用OR操作符,PG优化器走的是Bitmap Index Scan,使用IN,优化器选择的路径是Index Only Scan,相对于Bitmap Index Scan少了Bitmap的建立,成本自然要低不少。
OR and Join
在Join场景中,如果在参与join的表上都存在查询条件然后在where子句中应用OR关联,那么优化器会选择a和b连接然后使用Filter过滤,由于先进行join而没有进行谓词下推,因此为了得到1行而filter了999999行,代价巨大。
[local:/data/pg12]:5432 pg12@testdb=# EXPLAIN verbose SELECT id, a.a_val, b.b_valFROM a JOIN b USING (id)WHERE a.id = 42 OR b.id = 42; QUERY PLAN --------------------------------------------------------------------------------------------- Gather (cost=21965.00..45327.62 rows=2 width=70) Output: a.id, a.a_val, b.b_val Workers Planned: 2 -> Parallel Hash Join (cost=20965.00..44327.42 rows=1 width=70) Output: a.id, a.a_val, b.b_val Inner Unique: true Hash Cond: (a.id = b.id) Join Filter: ((a.id = 42) OR (b.id = 42)) -> Parallel Seq Scan on public.a (cost=0.00..12500.67 rows=416667 width=37) Output: a.id, a.a_val -> Parallel Hash (cost=12500.67..12500.67 rows=416667 width=37) Output: b.b_val, b.id -> Parallel Seq Scan on public.b (cost=0.00..12500.67 rows=416667 width=37) Output: b.b_val, b.id(14 rows)
在这种情况下,可以通过使用UNION来关联两个JOIN提升性能
[local:/data/pg12]:5432 pg12@testdb=# EXPLAIN verbosepg12@testdb-# SELECT id, a.a_val, b.b_valpg12@testdb-# FROM a JOIN b USING (id)pg12@testdb-# WHERE a.id = 42pg12@testdb-# UNIONpg12@testdb-# SELECT id, a.a_val, b.b_valpg12@testdb-# FROM a JOIN b USING (id)pg12@testdb-# WHERE b.id = 42pg12@testdb-# ; QUERY PLAN ---------------------------------------------------------------------------------------------------- Unique (cost=33.83..33.85 rows=2 width=68) Output: a.id, a.a_val, b.b_val -> Sort (cost=33.83..33.84 rows=2 width=68) Output: a.id, a.a_val, b.b_val Sort Key: a.id, a.a_val, b.b_val -> Append (cost=0.85..33.82 rows=2 width=68) -> Nested Loop (cost=0.85..16.90 rows=1 width=70) Output: a.id, a.a_val, b.b_val -> Index Scan using a_pkey on public.a (cost=0.42..8.44 rows=1 width=37) Output: a.id, a.a_val Index Cond: (a.id = 42) -> Index Scan using b_pkey on public.b (cost=0.42..8.44 rows=1 width=37) Output: b.id, b.b_val Index Cond: (b.id = 42) -> Nested Loop (cost=0.85..16.90 rows=1 width=70) Output: a_1.id, a_1.a_val, b_1.b_val -> Index Scan using a_pkey on public.a a_1 (cost=0.42..8.44 rows=1 width=37) Output: a_1.id, a_1.a_val Index Cond: (a_1.id = 42) -> Index Scan using b_pkey on public.b b_1 (cost=0.42..8.44 rows=1 width=37) Output: b_1.id, b_1.b_val Index Cond: (b_1.id = 42)(22 rows)[local:/data/pg12]:5432 pg12@testdb=#
两个子连接选择了成本最低的NL join,总成本是原来SQL语句成本的0.1%都不到,差了3个数量级。
"怎么正确使用PostgreSQL中的OR"的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站,小编将为大家输出更多高质量的实用文章!
成本
语句
选择
两个
内容
性能
情况
更多
条件
知识
关联
查询
不当
实用
巨大
最低
较差
学有所成
接下来
个数
数据库的安全要保护哪些东西
数据库安全各自的含义是什么
生产安全数据库录入
数据库的安全性及管理
数据库安全策略包含哪些
海淀数据库安全审计系统
建立农村房屋安全信息数据库
易用的数据库客户端支持安全管理
连接数据库失败ssl安全错误
数据库的锁怎样保障安全
互联网科技社
艾特科技互联网
上海亿帐通互联网科技
互联网科技类展会
丰台科技园 互联网公司
互联网科技创新企业排名
太原新华互联网科技学校怎么样
湖南洣水互联网科技有限公司扣款
港股科技和互联网
晓花互联网科技有限公司网址
深圳育鹏互联网科技有限公司招聘
中国科技创新与世界互联网大会
易企秀互联网科技是做什么的
新氧科技和美国互联网有关系吗
国产互联网科技公司
广州智享互联网科技
互联网科技手抄报图片
数字互联网科技有限公司
深圳互联网科技园地址
互联网的黑科技实验室
咖啡网
互联网科技资迅
科技信息互联网
盛创互联网科技有限公司
开一家科技互联网公司需要多少钱
互联网方面的科技前沿
山东子淼互联网科技有限公司
厦门江牛科技互联网
西安有哪些互联网高科技企业
陕西彩京云互联网科技有限公司