PostGreSQL不同索引类型(btree & hash)的性能问题
在关系型数据库调优中,查询语句涉及到的索引类型是不得不考虑的一个问题。不同的类型的索引可能会适用不同类型的业务场景。这里我们所说的索引类型指的是访问方法(Access Method),至于从其他维度区分索引(Index)这里暂不作考虑。
PostGreSQL数据库默认的索引访问方法是btree,其他的数据库如Oracle默认也是btree。那么btree到底是何方神圣呢?如果想要深入理解btree的运行原理,需要了解一下数据结构相关的知识,特别是树形数据结构。btree运用了b+ 树数据结构,其可以有效节省IO操作,在查询时可以提供查询效率。
我们沿用之前文章用过的查询语句来做测试,其中sort_test表有500万行数据。表创建SQL和查询语句如下:
CREATE TABLE public.sort_test
(
id bigint NOT NULL,
salary numeric NOT NULL,
CONSTRAINT sort_test_pkey PRIMARY KEY (id)
) TABLESPACE pg_default; explain analyze select * from public."sort_test" where salary = 101;
那么执行计划的细节如下图所示:
下面将在同样的表字段上,删除原来的索引,添加相应的hash索引。添加语句为:
CREATE INDEX index_sort_test_salary_hash
ON public.sort_test USING hash
(salary)
TABLESPACE pg_default;
添加完之后,如下图所示:
同样的查询语句的执行计划是怎样的呢?如下图:
可以发现0.757 ms vs. 0.022 ms还是有数量级的差别,在这种情况下,hash索引的效率比btree的效率要高很多。由于hash索引结构的特殊性,其检索效率非常高,可以一步到位。而一般使用的B-tree索引需要从根节点->枝节点->页节点。所以从工作模式上看,hash索引的效率要比btree索引要高。
但是我们大家都懂的,事务都有两面性,hash索引有一定的限制和弊端,要不然这些常用的数据库如Oracle, MySQL,PostGreSQL等也不会将btree access method设置为默认选项了。具体有如下2点限制:
Hash索引只能满足"=","IN"等,等值查询,不能使用范围查询。
在使用部分索引键查询的时候,hash索引将不起作用。
所以在应用不同的索引类型时,要充分考虑具体的业务场景和实际情况,才能得到更优解。
最新文章
- Unity自动寻路Navmesh之入门
- CocoaPods使用 主要带图。转载。
- websocket 403
- 用Python+Django在Eclipse环境下开发web网站【转】
- android138 360 小火箭
- Spring容器关于继承的应用案例
- 无图无定位新版css步骤条兼容ie6+
- git 撤销没有提交的变化
- Spring3.x企业应用开发实战-Spring+Hibernat架构分析
- ASP .NET Core HTTP Error 502.5 – Process Failure
- MyBatis:CRUD功能
- Kudu-压缩
- 利用log4添加log
- IBGP规划
- centos安装守护进程工具supervisor
- [转帖]Nginx的超时keeplive_timeout配置详解
- linux内核分析(网课期末&;地面课期中)
- Java并发和多线程那些事儿
- 《Implementing QuantLib》译后记
- Linux内核分析第五周——扒开系统调用的“三层皮”(下)