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

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介:

标签

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和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
1月前
|
数据库 索引
深入探索数据库索引技术:回表与索引下推解析
【10月更文挑战第15天】在数据库查询优化的领域中,回表和索引下推是两个核心概念,它们对于提高查询性能至关重要。本文将详细解释这两个术语,并探讨它们在数据库操作中的作用和影响。
46 3
|
1月前
|
数据库 索引
深入理解数据库索引技术:回表与索引下推详解
【10月更文挑战第23天】 在数据库查询性能优化中,索引的使用是提升查询效率的关键。然而,并非所有的索引都能直接加速查询。本文将深入探讨两个重要的数据库索引技术:回表和索引下推,解释它们的概念、工作原理以及对性能的影响。
51 3
|
7天前
|
存储 关系型数据库 数据库
【赵渝强老师】PostgreSQL的数据库集群
PostgreSQL的逻辑存储结构涵盖了数据库集群、数据库、表、索引、视图等对象,每个对象都有唯一的oid标识。数据库集群是由单个PostgreSQL实例管理的所有数据库集合,共享同一配置和资源。集群的数据存储在一个称为数据目录的单一目录中,可通过-D选项或PGDATA环境变量指定。
|
20天前
|
关系型数据库 分布式数据库 数据库
PostgreSQL+Citus分布式数据库
PostgreSQL+Citus分布式数据库
50 15
|
16天前
|
数据库 索引
数据库索引
数据库索引 1、索引:建立在表一列或多列的辅助对象,目的是加快访问表的数据。 2、索引的优点: (1)、创建唯一性索引,可以确保数据的唯一性; (2)、大大加快数据检索速度; (3)、加速表与表之间的连接; (4)、在查询过程中,使用优化隐藏器,提高系统性能。 3、索引的缺点: (1)、创建和维护索引需要耗费时间,随数据量增加而增加; (2)、索引占用物理空间; (3)、对表的数据进行增删改时,索引需要动态维护,降低了数据的维护速度。
32 2
|
2月前
|
存储 关系型数据库 MySQL
Mysql(4)—数据库索引
数据库索引是用于提高数据检索效率的数据结构,类似于书籍中的索引。它允许用户快速找到数据,而无需扫描整个表。MySQL中的索引可以显著提升查询速度,使数据库操作更加高效。索引的发展经历了从无索引、简单索引到B-树、哈希索引、位图索引、全文索引等多个阶段。
64 3
Mysql(4)—数据库索引
|
26天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型,以及如何创建和维护索引,结合实战案例分析查询执行计划,帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
144 1
|
28天前
|
SQL 关系型数据库 数据库
PostgreSQL性能飙升的秘密:这几个调优技巧让你的数据库查询速度翻倍!
【10月更文挑战第25天】本文介绍了几种有效提升 PostgreSQL 数据库查询效率的方法,包括索引优化、查询优化、配置优化和硬件优化。通过合理设计索引、编写高效 SQL 查询、调整配置参数和选择合适硬件,可以显著提高数据库性能。
156 1
|
1月前
|
存储 关系型数据库 MySQL
MySQL vs. PostgreSQL:选择适合你的开源数据库
在众多开源数据库中,MySQL和PostgreSQL无疑是最受欢迎的两个。它们都有着强大的功能、广泛的社区支持和丰富的生态系统。然而,它们在设计理念、性能特点、功能特性等方面存在着显著的差异。本文将从这三个方面对MySQL和PostgreSQL进行比较,以帮助您选择更适合您需求的开源数据库。
116 4
|
2月前
|
缓存 数据库 数据安全/隐私保护
Discuz! X 数据库字典详解:DZ各数据表作用及字段含义
我们使用DISCUZ做网站时,有时需要对数据表进行操作,在操作数据表之前,需要对数据表进行了解。下面是DISCUZ 数据库各数据表作用及字段含义详解,方便新手更好的了解DISCUZ数据库。
53 4

相关产品

  • 云原生数据库 PolarDB
  • 云数据库 RDS PostgreSQL 版