AI 助理
备案控制台
开发者社区 数据库 关系型数据库 文章 正文

PostgreSQL 数据库多列复合索引的字段顺序选择原理

2018-04-18 8081
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云原生数据库 PolarDB 分布式版，标准版 2核8GB
推荐场景：
使用PolarDB-X与Flink搭建实时数据大屏
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
RDS PostgreSQL Serverless，0.5-4RCU 50GB 3个月
推荐场景：
对影评进行热评分析
简介：

标签

PostgreSQL , 多列索引 , 复合索引 , 驱动列 , 顺序 , 等值查询 , 范围扫描 , 离散值 , 连续值 , 单列索引 , bitmap index scan

背景

当需要创建多列复合索引时，应该使用什么样的顺序呢？

多列复合索引的组织结构与单列字段索引结构类似，只是需要按索引内表达式指定的顺序编排。

《深入浅出PostgreSQL B-Tree索引结构》

例如

create index idx on tbl using btree (udf(c1) desc, c2 , c3 desc nulls last);

那么会按定义的顺序编排。

举个例子

postgres=# create unlogged table tab1 (id int, c1 int, c2 int);  
CREATE TABLE  
postgres=# insert into tab1 select id, random()*9, 1 from generate_series(1,1000000) t(id);  
INSERT 0 1000000  
postgres=# insert into tab1 select id, random()*9, 3 from generate_series(1,1000000) t(id);  
INSERT 0 1000000  
postgres=# insert into tab1 values (1,1,2);  
INSERT 0 1  
postgres=# insert into tab1 select id, 1, 3 from generate_series(1,1000000) t(id);  
INSERT 0 1000000  
postgres=# insert into tab1 select id, 1, 1 from generate_series(1,1000000) t(id);  
INSERT 0 1000000

c1=1, c2=2的记录只有一条

1、搜索c1=1, c2=2，只需要扫描4个BLOCK

postgres=# explain (analyze,verbose,timing,costs,buffers) select * from tab1 where c1=1 and c2=2;  
                                                      QUERY PLAN                                                         
-----------------------------------------------------------------------------------------------------------------------  
 Index Scan using idx_tab1 on public.tab1  (cost=0.43..2.38 rows=1 width=12) (actual time=0.017..0.018 rows=1 loops=1)  
   Output: id, c1, c2  
   Index Cond: ((tab1.c1 = 1) AND (tab1.c2 = 2))  
   Buffers: shared hit=4  （4个BLOCK，包括 root page, branch page, leaf page, HEAP PAGE）  
 Planning time: 0.214 ms  
 Execution time: 0.042 ms  
(6 rows)

2、搜索其他的，需要扫描很多BLOCK。

postgres=# explain (analyze,verbose,timing,costs,buffers) select * from tab1 where c1=1 and c2=3;  
                                                               QUERY PLAN                                                                  
-----------------------------------------------------------------------------------------------------------------------------------------  
 Index Scan using idx_tab1 on public.tab1  (cost=0.43..46108.77 rows=1109400 width=12) (actual time=0.026..237.712 rows=1111519 loops=1)  
   Output: id, c1, c2  
   Index Cond: ((tab1.c1 = 1) AND (tab1.c2 = 3))  
   Buffers: shared hit=22593 read=303   (包括heap page)  
 Planning time: 0.089 ms  
 Execution time: 328.249 ms  
(6 rows)  
  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from tab1 where c1=1 and c2=1;  
                                                               QUERY PLAN                                                                  
-----------------------------------------------------------------------------------------------------------------------------------------  
 Index Scan using idx_tab1 on public.tab1  (cost=0.43..46108.77 rows=1109400 width=12) (actual time=0.022..238.399 rows=1110527 loops=1)  
   Output: id, c1, c2  
   Index Cond: ((tab1.c1 = 1) AND (tab1.c2 = 1))   
   Buffers: shared hit=22582 read=299   (包括heap page)  
 Planning time: 0.094 ms  
 Execution time: 329.331 ms  
(6 rows)

那么如何知道数据库是快速定位到c1=1, c2=2的记录的呢？

可以使用pageinspect来看一看索引内部的结构

postgres=# create extension pageinspect ;  
CREATE EXTENSION

查看索引内部结构，看看如何通过复合索引快速定位一条记录

首先要查看索引的第一个PAGE，即metapage，它会告诉你这个索引有几层，ROOT PAGE在哪里

postgres=# SELECT * FROM bt_metap('idx_tab1');   
 magic  | version | root | level | fastroot | fastlevel   
--------+---------+------+-------+----------+-----------  
 340322 |       2 |  290 |     2 |      290 |         2  
(1 row)

表示这个索引除去ROOT节点有2层，ROOT节点是290号数据块。

查看根页

postgres=# SELECT * FROM bt_page_items('idx_tab1', 290);   
 itemoffset |   ctid    | itemlen | nulls | vars |          data             
------------+-----------+---------+-------+------+-------------------------  
          1 | (3,1)     |       8 | f     | f    |   
          2 | (289,1)   |      16 | f     | f    | 00 00 00 00 03 00 00 00  
          3 | (12341,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          4 | (12124,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          5 | (11907,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          6 | (11690,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          7 | (11473,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          8 | (11256,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          9 | (11039,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         10 | (10822,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         11 | (10605,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         12 | (10388,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         13 | (10171,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         14 | (9954,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         15 | (9737,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         16 | (9520,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         17 | (9303,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         18 | (9086,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         19 | (575,1)   |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         20 | (8866,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         21 | (8649,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         22 | (8432,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         23 | (8215,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         24 | (7998,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         25 | (7781,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         26 | (7564,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         27 | (7347,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         28 | (7130,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         29 | (6913,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         30 | (6696,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         31 | (6479,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         32 | (6262,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         33 | (6045,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         34 | (5828,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         35 | (5611,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         36 | (860,1)   |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         37 | (1145,1)  |      16 | f     | f    | 02 00 00 00 01 00 00 00  
         38 | (1430,1)  |      16 | f     | f    | 02 00 00 00 03 00 00 00  
         39 | (1715,1)  |      16 | f     | f    | 03 00 00 00 01 00 00 00  
         40 | (2000,1)  |      16 | f     | f    | 03 00 00 00 03 00 00 00  
         41 | (2285,1)  |      16 | f     | f    | 04 00 00 00 01 00 00 00  
         42 | (2570,1)  |      16 | f     | f    | 04 00 00 00 03 00 00 00  
         43 | (2855,1)  |      16 | f     | f    | 05 00 00 00 01 00 00 00  
         44 | (3140,1)  |      16 | f     | f    | 05 00 00 00 03 00 00 00  
         45 | (3425,1)  |      16 | f     | f    | 06 00 00 00 01 00 00 00  
         46 | (3710,1)  |      16 | f     | f    | 06 00 00 00 03 00 00 00  
         47 | (3995,1)  |      16 | f     | f    | 07 00 00 00 01 00 00 00  
         48 | (4280,1)  |      16 | f     | f    | 07 00 00 00 03 00 00 00  
         49 | (4565,1)  |      16 | f     | f    | 07 00 00 00 03 00 00 00  
         50 | (4850,1)  |      16 | f     | f    | 08 00 00 00 01 00 00 00  
         51 | (5135,1)  |      16 | f     | f    | 08 00 00 00 03 00 00 00  
         52 | (5420,1)  |      16 | f     | f    | 09 00 00 00 03 00 00 00  
(52 rows)

索引的非leaf节点，data表示这个PAGE的最小边界值，最左边的页没有最小值

如何快速找到c1=1 and c2=2，通过以上信息，可以知道1,2在575号数据块中。

         19 | (575,1)   |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         20 | (8866,1)  |      16 | f     | f    | 01 00 00 00 03 00 00 00

继续查看575号索引页的内容。这个页是第一层（不是最后一层），分支节点

第一条表示与当前页右边的相邻页，data是它的最小值。第二条表示当前页左边的相邻页，data为空。

postgres=# SELECT * FROM bt_page_items('idx_tab1', 575);   
 itemoffset |   ctid   | itemlen | nulls | vars |          data             
------------+----------+---------+-------+------+-------------------------  
          1 | (8712,1) |      16 | f     | f    | 01 00 00 00 03 00 00 00  
          2 | (572,1)  |       8 | f     | f    |   
          3 | (573,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          4 | (574,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          5 | (576,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          6 | (577,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          7 | (578,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          8 | (579,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          9 | (580,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         10 | (581,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         11 | (582,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         12 | (583,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         13 | (584,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         14 | (585,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         15 | (586,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         16 | (587,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         17 | (588,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         18 | (589,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         19 | (590,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         20 | (591,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         21 | (592,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         22 | (593,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         23 | (594,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         24 | (595,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         25 | (596,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         26 | (597,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         27 | (598,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         28 | (599,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         29 | (600,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         30 | (601,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         31 | (602,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         32 | (603,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         33 | (604,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         34 | (605,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         35 | (606,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         36 | (607,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         37 | (608,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         38 | (609,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         39 | (610,1)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         40 | (5488,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         41 | (8961,1) |      16 | f     | f    | 01 00 00 00 03 00 00 00  
         42 | (8960,1) |      16 | f     | f    | 01 00 00 00 03 00 00 00  
。。。。。。。。。。。。。。

通过这两行，找到了c1=1.c2=2应该在5488号索引页中。

         40 | (5488,1) |      16 | f     | f    | 01 00 00 00 01 00 00 00  
         41 | (8961,1) |      16 | f     | f    | 01 00 00 00 03 00 00 00

继续搜索索引也，第二层（最后一层），叶子节点

postgres=# SELECT * FROM bt_page_items('idx_tab1', 5488);   
 itemoffset |    ctid     | itemlen | nulls | vars |          data             
------------+-------------+---------+-------+------+-------------------------  
          1 | (16215,25)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
          2 | (5398,127)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          3 | (5398,137)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          4 | (5398,156)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
          5 | (5398,172)  |      16 | f     | f    | 01 00 00 00 01 00 00 00  
.....  
  
        130 | (5405,10)   |      16 | f     | f    | 01 00 00 00 01 00 00 00  
        131 | (5405,15)   |      16 | f     | f    | 01 00 00 00 01 00 00 00  
        132 | (5405,17)   |      16 | f     | f    | 01 00 00 00 01 00 00 00  
        133 | (5405,35)   |      16 | f     | f    | 01 00 00 00 01 00 00 00  
        134 | (5405,59)   |      16 | f     | f    | 01 00 00 00 01 00 00 00  
        135 | (10810,151) |      16 | f     | f    | 01 00 00 00 02 00 00 00  
        136 | (16216,41)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
        137 | (16216,40)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
        138 | (16216,39)  |      16 | f     | f    | 01 00 00 00 03 00 00 00  
...

找到记录

HEAP PAGE

        135 | (10810,151) |      16 | f     | f    | 01 00 00 00 02 00 00 00

因为是叶子节点，所以ctid表示的是HEAP的偏移值，直接在HEAP PAGE中查看

postgres=# select * from tab1 where ctid='(10810,151)';  
 id | c1 | c2   
----+----+----  
  1 |  1 |  2  
(1 row)

在了解了多列索引的内部结构后，可以来看一下几种查询场景的优化

例子 - 范围+等值查询

驱动列使用范围条件，第二列使用等值条件

虽然走了索引，但是扫描了第一列的所有索引页。

性能不佳

postgres=# explain (analyze,verbose,timing,costs,buffers) select * from tab1 where c1 between 1 and 9 and c2=2;  
                                                         QUERY PLAN                                                            
-----------------------------------------------------------------------------------------------------------------------------  
 Index Scan using idx_tab1 on public.tab1  (cost=0.43..60757.38 rows=1 width=12) (actual time=0.027..106.362 rows=1 loops=1)  
   Output: id, c1, c2  
   Index Cond: ((tab1.c1 >= 1) AND (tab1.c1 <= 9) AND (tab1.c2 = 2))  
   Buffers: shared hit=8321  
 Planning time: 0.099 ms  
 Execution time: 106.422 ms  
(6 rows)

优化

新建复合索引，将等值列放在前面

postgres=# create index idx_tab1_2 on tab1 using btree (c2,c1);  
CREATE INDEX

等值条件直接被过滤，只需要扫描一条索引ITEM

postgres=# explain (analyze,verbose,timing,costs,buffers) select * from tab1 where c1 between 1 and 9 and c2=2;  
                                                       QUERY PLAN                                                          
-------------------------------------------------------------------------------------------------------------------------  
 Index Scan using idx_tab1_2 on public.tab1  (cost=0.43..2.35 rows=1 width=12) (actual time=0.017..0.018 rows=1 loops=1)  
   Output: id, c1, c2  
   Index Cond: ((tab1.c2 = 2) AND (tab1.c1 >= 1) AND (tab1.c1 <= 9))  
   Buffers: shared hit=4  
 Planning time: 0.095 ms  
 Execution time: 0.040 ms  
(6 rows)

例子 - 多值+等值查询

PostgreSQL针对离散多值查询，有一定的优化，仅仅扫描了多个离散值的索引ITEM

drop index idx_tab1_2;  
  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from tab1 where c1 in (1,2,3,4,5,6,7,8,9) and c2=2;  
                                                       QUERY PLAN                                                         
------------------------------------------------------------------------------------------------------------------------  
 Index Scan using idx_tab1 on public.tab1  (cost=0.43..13.90 rows=1 width=12) (actual time=0.024..0.186 rows=1 loops=1)  
   Output: id, c1, c2  
   Index Cond: ((tab1.c1 = ANY ('{1,2,3,4,5,6,7,8,9}'::integer[])) AND (tab1.c2 = 2))  
   Buffers: shared hit=21 read=7  
 Planning time: 0.114 ms  
 Execution time: 0.208 ms  
(6 rows)

而如果将单值列放在前面，多值列放在后面，扫描的BLOCK会更少，但是会将离散过滤条件作为FILTER条件。

postgres=# create index idx_tab1_2 on tab1 using btree (c2,c1);  
CREATE INDEX  
  
postgres=# explain (analyze,verbose,timing,costs,buffers) select * from tab1 where c1 in (1,2,3,4,5,6,7,8,9) and c2=2;  
                                                       QUERY PLAN                                                          
-------------------------------------------------------------------------------------------------------------------------  
 Index Scan using idx_tab1_2 on public.tab1  (cost=0.43..2.35 rows=1 width=12) (actual time=0.027..0.027 rows=1 loops=1)  
   Output: id, c1, c2  
   Index Cond: (tab1.c2 = 2)  
   Filter: (tab1.c1 = ANY ('{1,2,3,4,5,6,7,8,9}'::integer[]))  
   Buffers: shared hit=4  
 Planning time: 0.107 ms  
 Execution time: 0.047 ms  
(7 rows)

因为c2=2是驱动列，使用第二个索引，可以直接命中到1条item，其他的不需要扫到，所以快了很多。

假设有两个索引存在，对于数据存在倾斜的情况，数据库会根据过滤性自动选择合适的索引。

小结

PostgreSQL目前还不支持非连续性的索引扫描，所以当驱动列（第一列）使用了范围扫描后，即使复合索引有第二列，并且第二列是个等值查询，那么也要扫描第一列范围覆盖的所有索引。

这样就出现了索引页扫描的IO放大（因为可能扫了一些实际条件不符的INDEX PAGE）。

多列复合索引的创建建议：

1、离散查询条件（例如 等值）的列放在最前面，如果一个复合查询中有多个等值查询的列，尽量将选择性好（count(distinct) 值多的）的放在前面。

2、离散查询条件（例如 多值）的列放在后面，如果一个复合查询中有多个多值查询的列，尽量将选择性好（count(distinct) 值多的）的放在前面。

3、连续查询条件（例如 范围查询）的列放在最后面，如果一个复合查询中有多个多值查询的列，尽量将输入范围条件返回结果集少的列放前面，提高筛选效率（同时也减少索引扫描的范围）。

4、如果返回的结果集非常大（或者说条件命中率很高），并且属于流式返回（或需要高效率优先返回前面几条记录），同时有排序输出的需求。建议按排序键建立索引。

参考

《PostgreSQL bitmapAnd, bitmapOr, bitmap index scan, bitmap heap scan》

《深入浅出PostgreSQL B-Tree索引结构》

https://www.postgresql.org/docs/devel/static/pageinspect.html

文章标签：
云原生数据库 PolarDB
索引
关系型数据库
数据库
PostgreSQL
C语言
关键词：
数据库索引
postgresql数据库
数据库字段
数据库postgresql
PostgreSQL索引
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系，提升产品性能，打磨产品功能，从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手，打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系， 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台，为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案，提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
德哥
目录
相关文章
潇洒洒
|
24天前
|
数据库 索引
深入探索数据库索引技术：回表与索引下推解析
【10月更文挑战第15天】在数据库查询优化的领域中，回表和索引下推是两个核心概念，它们对于提高查询性能至关重要。本文将详细解释这两个术语，并探讨它们在数据库操作中的作用和影响。
潇洒洒
43 3
最好zzz
|
24天前
|
数据库 索引
深入理解数据库索引技术：回表与索引下推详解
【10月更文挑战第23天】 在数据库查询性能优化中，索引的使用是提升查询效率的关键。然而，并非所有的索引都能直接加速查询。本文将深入探讨两个重要的数据库索引技术：回表和索引下推，解释它们的概念、工作原理以及对性能的影响。
最好zzz
45 3
Skyund
|
10天前
|
数据库 索引
数据库索引
数据库索引 1、索引：建立在表一列或多列的辅助对象，目的是加快访问表的数据。 2、索引的优点： (1)、创建唯一性索引，可以确保数据的唯一性； (2)、大大加快数据检索速度； (3)、加速表与表之间的连接； (4)、在查询过程中，使用优化隐藏器，提高系统性能。 3、索引的缺点： (1)、创建和维护索引需要耗费时间，随数据量增加而增加； (2)、索引占用物理空间； (3)、对表的数据进行增删改时，索引需要动态维护，降低了数据的维护速度。
Skyund
24 2
土木林森
|
20天前
|
监控 关系型数据库 MySQL
数据库优化：MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型，以及如何创建和维护索引，结合实战案例分析查询执行计划，帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
土木林森
97 1
东方睿赢
|
21天前
|
存储 Java 关系型数据库
在Java开发中，数据库连接是应用与数据交互的关键环节。本文通过案例分析，深入探讨Java连接池的原理与最佳实践
在Java开发中，数据库连接是应用与数据交互的关键环节。本文通过案例分析，深入探讨Java连接池的原理与最佳实践，包括连接创建、分配、复用和释放等操作，并通过电商应用实例展示了如何选择合适的连接池库（如HikariCP）和配置参数，实现高效、稳定的数据库连接管理。
东方睿赢
40 2
付兴森
|
28天前
|
缓存 数据库 数据安全/隐私保护
Discuz! X 数据库字典详解：DZ各数据表作用及字段含义
我们使用DISCUZ做网站时，有时需要对数据表进行操作，在操作数据表之前，需要对数据表进行了解。下面是DISCUZ 数据库各数据表作用及字段含义详解，方便新手更好的了解DISCUZ数据库。
付兴森
48 4
蓝易云
|
14天前
|
存储 关系型数据库 数据库
Postgres数据库BRIN索引介绍
BRIN索引是PostgreSQL提供的一种高效、轻量级的索引类型，特别适用于大规模、顺序数据的范围查询。通过存储数据块的摘要信息，BRIN索引在降低存储和维护成本的同时，提供了良好的查询性能。然而，其适用场景有限，不适合随机数据分布或频繁更新的场景。在选择索引类型时，需根据数据特性和查询需求进行权衡。希望本文对你理解和使用PostgreSQL的BRIN索引有所帮助。
蓝易云
25 0
土木林森
|
21天前
|
监控 关系型数据库 MySQL
数据库优化：MySQL索引策略与查询性能调优实战
【10月更文挑战第26天】数据库作为现代应用系统的核心组件，其性能优化至关重要。本文主要探讨MySQL的索引策略与查询性能调优。通过合理创建索引（如B-Tree、复合索引）和优化查询语句（如使用EXPLAIN、优化分页查询），可以显著提升数据库的响应速度和稳定性。实践中还需定期审查慢查询日志，持续优化性能。
土木林森
49 0
路卿老师
|
11天前
|
SQL 关系型数据库 MySQL
12 PHP配置数据库MySQL
路老师分享了PHP操作MySQL数据库的方法，包括安装并连接MySQL服务器、选择数据库、执行SQL语句（如插入、更新、删除和查询），以及将结果集返回到数组。通过具体示例代码，详细介绍了每一步的操作流程，帮助读者快速入门PHP与MySQL的交互。
路卿老师
26 1
听风de歌
|
13天前
|
SQL 关系型数据库 MySQL
go语言数据库中mysql驱动安装
【11月更文挑战第2天】
听风de歌
29 4
数据库

关系型数据库

热门文章

最新文章

  • 1
    浅析MySQL优化器统计信息
  • 2
    PostgreSQL 9种索引的原理和应用场景
  • 3
    RDS MySQL Adaptive Hash Index (AHI)最佳实践
  • 4
    Linux 多核下绑定硬件中断到不同 CPU（IRQ Affinity）
  • 5
    阿里云RDS服务巴黎奥运会赛事系统，助力云上奥运稳定运行
  • 6
    达梦(DM) SQL日期操作及分析函数
  • 7
    PostgreSQL 整型int与布尔boolean的自动转换设置(含自定义cast与cast规则介绍)
  • 8
    PostgreSQL 11 preview - 分页内核层优化 - 索引扫描offset优化(使用vm文件skip heap scan)
  • 9
    介绍几种 MySQL 官方高可用方案
  • 10
    MySQL安全与权限管理：保障数据安全与访问控制
  • 1
    【赵渝强老师】PostgreSQL的数据库集群
    11
  • 2
    【赵渝强老师】PostgreSQL的逻辑存储结构
    27
  • 3
    【赵渝强老师】MySQL的参数文件
    34
  • 4
    【赵渝强老师】MySQL的全量日志文件
    24
  • 5
    【赵渝强老师】MySQL的慢查询日志
    38
  • 6
    Pgloader极简教程
    34
  • 7
    【赵渝强老师】MySQL的binlog日志文件
    36
  • 8
    【赵渝强老师】MySQL的撤销日志文件和错误日志文件
    23
  • 9
    【赵渝强老师】MySQL InnoDB的段、区和页
    32
  • 10
    【赵渝强老师】MySQL InnoDB的表空间
    35

    • 相关产品

  • 云原生数据库 PolarDB
    文档详情 产品详情
  • 云数据库 RDS PostgreSQL 版
    文档详情 产品详情

    • 相关课程

    更多
  • 数据库的前世今生
  • 数据库核心概念
  • 从传统数据库到云数据库演进
  • 数据库常见问题排查
  • 数据库及SQL/MySQL基础
  • 高校精品课-西安交通大学 -数据库理论与技术

    • 相关电子书

    更多
  • DTCC 2022大会集锦《云原生一站式数据库技术与实践》
  • 阿里云瑶池数据库精要2022版
  • 2022 DTCC-阿里云一站式数据库上云最佳实践

    • 相关实验场景

    更多
  • 使用DAS实现数据库SQL优化
  • 自建数据库迁移到云数据库
  • PolarDB for AI：在数据库中通过SQL实现AI能力
  • 云原生HTAP数据库，让你的交易和分析一库搞定
  • PolarDB for PostgreSQL 闪回特性体验
  • 快速体验PolarDB开源数据库

    • 推荐镜像

    更多
  • postgresql
  • mongodb
  • clickhouse
    • 下一篇
    无影云桌面