如何解决PostgreSQL索引最佳实践/性能
我在10.13上有一个测试Postgresql,正在寻找索引的几个答案。让我们以该表为例,并承认其中有40k条目:
CREATE TABLE "public"."ecom_input"
(
"id" serial PRIMARY KEY,"ecom_id" INTEGER NOT NULL,"sku_supplier" CHARACTER VARYING(100) NOT NULL
);
- 主键是否自动具有自己的索引? 使用此查询:
EXPLAIN SELECT * FROM ecom_input WHERE id = 27846;
无论使用PRIMARY KEY还是INDEX,我都有相同的结果:
--> Index Scan using ecom_input_pkey on ecom_input (cost=0.29..8.31 rows=1 width=853)
--> Index Scan using "ecom_input_id_idx" on ecom_input (cost=0.29..8.31 rows=1 width=853)
- 在同一张表上创建多列INDEX之后:
CREATE INDEX idx_ecom_input ON ecom_input (ecom_id,sku_supplier);
尝试:
EXPLAIN SELECT * FROM ecom_input WHERE ecom_id = 22 AND sku_supplier = 'MATHILDEJAS';
我具有良好的性价比:
--> Index Scan using idx_ecom_input on ecom_input (cost=0.41..8.43 rows=1 width=853)
仅使用WHERE sku_supplier = 'MATHILDEJAS';
时会降低性能:
--> Index Scan using idx_ecom_input on ecom_input (cost=0.41..1044.64 rows=1 width=853)
但是仅使用WHERE ecom_id = 22;
时:
--> Bitmap Heap Scan on ecom_input (cost=5.58..547.25 rows=150 width=853)
Recheck Cond: (ecom_id = 22)
-> Bitmap Index Scan on idx_ecom_input (cost=0.00..5.54 rows=150 width=0)
Index Cond: (ecom_id = 22)
为什么仅在WHERE子句中使用ecom_id而不在WHERE子句中使用sku_supplier时,优化器为什么使用位图堆扫描? ecom_id = 22的行有150行,而sku_supplier ='MATHILDEJAS'的行只有1行,这是原因吗?
-
我们通常在表的“ id”列(即PRIMARY KEYS)上进行JOIN操作。 JOIN操作期间是否使用INDEX?如果是,总是加入主键是否是一个好习惯?
-
在使用INDEX进行查询时和在不使用NOT进行查询时,在什么时候(大约)可以看到真正的性能差异?我们正在使用基于云的数据库,即使网络连接良好,通过Internet的往返服务器-客户端所需的时间也更长。
示例:
EXPLAIN ANALYZE SELECT * FROM ecom_input WHERE sku_supplier = 'MATHILDEJAS' AND ecom_id = 22;
使用INDEX:
"Index Scan using idx_ecom_input on ecom_input (cost=0.41..8.43 rows=1 width=853) (actual time=0.017..0.018 rows=1 loops=1)"
"Index Cond: ((ecom_id = 22) AND ((sku_supplier)::text = 'MATHILDEJAS'::text))"
"Planning time: 0.086 ms"
"Execution time: 0.034 ms"
没有INDEX:
"Seq Scan on ecom_input (cost=0.00..10034.43 rows=1 width=853) (actual time=0.006..13.555 rows=1 loops=1)"
"Filter: (((sku_supplier)::text = 'MATHILDEJAS'::text) AND (ecom_id = 22))"
"Rows Removed by Filter: 40561"
"Planning time: 0.097 ms"
"Execution time: 13.572 ms"
我们总共获得13毫秒的时间。此请求最多需要250-700ms才能到达服务器并返回。它不会真正影响40k条目表。您知道多少个条目和INDEX有用吗?
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。