探讨select in 在postgresql的效率问题

这篇文章主要介绍了探讨select in 在postgresql的效率问题的相关资料,需要的朋友可以参考下

在知乎上看到这样一个问题：

MySQL 查询 select * from table where id in (几百或几千个 id) 如何提高效率？修改

电商网站，一个商品属性表，几十万条记录，80M，索引只有主键id，做这样的查询如何提高效率？

select * from table where id in (几百或几千个id)

这些id没啥规律，分散的。。。。

看了一下答案，感觉有好多不靠谱的，但是口说无凭，所以在我的电脑上写了几个查询测试一下。我用的是Postgresql9.4，但感觉mysql应该也差不多，首先创建一个简单表，只有简单的3列，在这个问题的下面好多人提到了需要看表的大小，其实这个问题和表大小无关，只和index的大小有关，因为是index是建立在int上的，所以只和纪录数目有关。

Table "public.t9"
Column | Type | Modifiers
--------+----------------+-----------
c1 | integer |
c2 | character(100) |
c3 | character(200) |
Indexes:
"i1" UNIQUE, btree (c1)insert into t9 values(generate_series(1000,500000,1),repeat('a',90),repeat('b',180));

之后生成一些随机数，Mac上用jot，Linux上用shuf

for ((i=0;i<100000;i++))
do
jot -r 1 1000 600000 >>rand.file
done

然后根据rand.file 生成查询语句：

select * from t9 where c1 in (
494613,
575087,
363588,
527650,
251670,
343456,
426858,
202886,
254037,
...
1
);

分别生成3个sql文件，in内变量的数目分别是100，1000和10000个，执行这3个sql文件，看看时间

try psql study -f test_100.sql -o /dev/null
LOG: duration: 2.879 ms
try psql study -f test_1000.sql -o /dev/null
LOG: duration: 11.974 ms
try psql study -f test_10000.sql -o /dev/null
LOG: duration: 355.689 ms

可以看到只有在in内数据到了10，000个的时候数据时间会有比较大的变化，但也不过是在300多ms内完成。

那如果按照有些回答那样，先建一个临时表，然后用in subquery，并且希望这时候可以两表join呢？为了简单我直接用两表join了

drop table t_tmp;
create table t_tmp(id int);
insert into t_tmp (id) values
(494613),
(575087),
(363588),
(345980),...
(1);
select t9.* from t9, t_tmp
where t9.c1 = t_tmp.id;

时间如何呢？

try psql study -f test_create_10000.sql -o /dev/null
LOG: duration: 2.078 ms
LOG: duration: 1.233 ms
LOG: duration: 224.112 ms
LOG: duration: 322.108 ms

除去drop和create的时间，依然花费了500+的时间，这里的前提还是我用的ssd盘，所以写LOG的时间会快很多。为什么会这么慢呢？用explain看一下，这时候数据量较大，直接走Merge join 了

那1000行数据的效率如何呢？

try psql study -f test_create_1000.sql -o exp.out
LOG: duration: 2.476 ms
LOG: duration: 0.967 ms
LOG: duration: 2.391 ms
LOG: duration: 8.780 ms

100行的数据如下：

try psql study -f test_create_100.sql -o /dev/null
LOG: duration: 2.020 ms
LOG: duration: 1.028 ms
LOG: duration: 1.074 ms
LOG: duration: 1.912 ms

可以看到在100个值和1000个值的情况下create table的方式不会比直接在in里面写所有的变量好多少，explain看的话是在用NLJ了。但在数据量更大（按照原问题，这里in的数量其实无法预知）的情况下效率只会更低，再加上额外的表维护成本和多余的SQL语句，DBA肯定不喜欢的，还是相信数据库，放心大胆直接用in list来搞定这些问题吧。

以上内容是针对select in 在postgresql的效率问题，希望对大家有所帮助！

转自: http://www.jb51.net/article/81980.htm

探讨select in 在postgresql的效率问题相关推荐

一条 Select 语句在 Postgresql 中的执行链路
本文只是逻辑上的概览,并没有太过深入的设计细节的描述,对应的postgresql 的代码版本是 REL_12_2 1. DML 语句入口如何搭建 gdb 调试pg 源代码环境,可以参考:利用GDB ...
select count mysql_mysql select count 与 select count 两个执行效率怎样
1 row in set, 1 warning (0.00 sec) 这样的好处是写法简单,用的是 MySQL 自己的语法.缺点也有,大概有两点:1. sql_calc_found_rows 是全表扫 ...
postgresql 索引之 bloom
os: ubuntu 16.04 db: postgresql 9.6.8 pg_log_userqueries: 1.1.1 bloom提供了一种基于布鲁姆过滤器的索引访问方法. 布鲁姆过滤器是一种 ...
postgresql应用开发者指南
内容基本SQL语法数据类型和操作符数据库对象类型高级SQL用法事务隔离级别锁触发器.事件触发器.规则表继承和分区表异步消息基本SQL语法大小写建表 select into &a ...
PostgreSQL 全文检索加速快到没有朋友 - RUM索引接口(潘多拉魔盒)
PostgreSQL 全文检索加速快到没有朋友 - RUM索引接口(潘多拉魔盒) 作者 digoal 日期 2016-10-19 标签 PostgreSQL , RUM , GIN , full t ...
PostgreSQL 区块链条管理举例
标签 PostgreSQL , blockchain , 链条管理 , 递归查询背景区块链的概念请参考 https://github.com/yeasy/blockchain_guide/blob ...
朴素、Select、Poll和Epoll网络编程模型实现和分析——朴素模型
做Linux网络开发,一般绕不开标题中几种网络编程模型.网上已有很多写的不错的分析文章,它们的基本论点是差不多的.但是我觉得他们讲的还不够详细,在一些关键论点上缺乏数据支持.所以我决定好好研究这几个模 ...
了解大脑的“小情绪”，轻松成为“效率达人”
知乎上有个高赞问题:你最想改变的习惯是什么? 很多人的答案是:拖延. 人人都想提高效率,而拖延就像效率的反义词,让人们避之不及,又挥之不去. 心理学家阿德勒说:"每个人的行为背后,都有一定的 ...
CentOS6.9编译安装postgresql和php的pdo_pgsql,pgsql扩展
1.安装依赖 yum install gcc gcc-c++ make readline-devel flex zlib-devel 2.下载源码,解压创建源码存放目录 mkdir -p /usr/ ...

探讨select in 在postgresql的效率问题

探讨select in 在postgresql的效率问题相关推荐

最新文章

热门文章