這篇文章主要講解了“PostgreSQL數(shù)據(jù)庫B-Tree索引的物理存儲結構是怎樣的”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“PostgreSQL數(shù)據(jù)庫B-Tree索引的物理存儲結構是怎樣的”吧！

創(chuàng)新互聯(lián)服務項目包括遼陽網(wǎng)站建設、遼陽網(wǎng)站制作、遼陽網(wǎng)頁制作以及遼陽網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，遼陽網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到遼陽省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！

一、測試數(shù)據(jù)

我們繼續(xù)使用上一節(jié)使用的測試數(shù)據(jù)，這一次我們追加插入>1000行的數(shù)據(jù)。

-- 為方便對比，插入數(shù)據(jù)前先查看索引元數(shù)據(jù)頁
testdb=# select * from bt_metap('pk_t_index');
 magic  | version | root | level | fastroot | fastlevel | oldest_xact | last_cleanup_num_tuples 
--------+---------+------+-------+----------+-----------+-------------+-------------------------
 340322 |       3 |    1 |     0 |        1 |         0 |           0 |                      -1
(1 row)

testdb=# do $$
testdb$# begin
testdb$#   for i in 19..1020 loop
testdb$#   insert into t_index (id, c1, c2) values (i, '#'||i||'#', '#'||i||'#');
testdb$#   end loop;
testdb$# end $$;
DO
testdb=# select count(*) from t_index;
 count 
-------
  1008
(1 row)

二、索引存儲結構

插入數(shù)據(jù)后，重新查看索引元數(shù)據(jù)頁信息：

testdb=# select * from bt_metap('pk_t_index');
 magic  | version | root | level | fastroot | fastlevel | oldest_xact | last_cleanup_num_tuples 
--------+---------+------+-------+----------+-----------+-------------+-------------------------
 340322 |       3 |    3 |     1 |        3 |         1 |           0 |                      -1
(1 row)

root block從原來的block 1變?yōu)閎lock 3，查看block 3的的Special space：

testdb=# select * from bt_page_stats('pk_t_index',3);
 blkno | type | live_items | dead_items | avg_item_size | page_size | free_size | btpo_prev | btpo_next | btpo | btpo_flags 
-------+------+------------+------------+---------------+-----------+-----------+-----------+-----------+------+------------
     3 | r    |          3 |          0 |            13 |      8192 |      8096 |         0 |         0 |    1 |          2
(1 row)

type=r，表示root index block，這個block有3個index entries（live_items=3，該index block只是root block（btpo_flags=BTP_ROOT）。下面我們來看看這個block中的index entries：

testdb=# select * from bt_page_items('pk_t_index',3);
 itemoffset |  ctid   | itemlen | nulls | vars |          data           
------------+---------+---------+-------+------+-------------------------
          1 | (1,0)   |       8 | f     | f    | 
          2 | (2,53)  |      16 | f     | f    | 7b 01 00 00 00 00 00 00
          3 | (4,105) |      16 | f     | f    | e9 02 00 00 00 00 00 00
(3 rows)

root/branch index block存儲的是指向其他index block的指針。第1行，index entries指向第1個index block，由于該block沒有l(wèi)eft block，因此，itemlen只有8個字節(jié)，數(shù)據(jù)范圍為1-\x0000017b（十進制值為379）；第2行，index entries指向第2個index block，數(shù)據(jù)范圍為380-\x000002e9（745）；第3行，index entries指向第4個index block，數(shù)據(jù)范圍為大于745的值。
這里有個疑惑，正常來說，root index block中的entries應指向index block，但ctid的值（2,53）和（4,105）指向的卻是Heap Table Block，PG11 Beta2的Bug？

In a B-tree leaf page, ctid points to a heap tuple. In an internal page, the block number part of ctid points to another page in the index itself, while the offset part (the second number) is ignored and is usually 1.

testdb=# select * from heap_page_items(get_raw_page('t_index',2)) where t_ctid = '(2,53)';
 lp | lp_off | lp_flags | lp_len | t_xmin  | t_xmax | t_field3 | t_ctid | t_infomask2 | t_infomask | t_hoff | t_bits | t_oid |                  t_data                  
----+--------+----------+--------+---------+--------+----------+--------+-------------+------------+--------+--------+-------+------------------------------------------
 53 |   5648 |        1 |     43 | 1612755 |      0 |      360 | (2,53) |           3 |       2306 |     24 |        |       | \x7b0100001323333739232020200d2333373923
(1 row)

testdb=# select * from heap_page_items(get_raw_page('t_index',4)) where t_ctid = '(4,105)';
 lp  | lp_off | lp_flags | lp_len | t_xmin  | t_xmax | t_field3 | t_ctid  | t_infomask2 | t_infomask | t_hoff | t_bits | t_oid |                  t_data                  
-----+--------+----------+--------+---------+--------+----------+---------+-------------+------------+--------+--------+-------+------------------------------------------
 105 |   3152 |        1 |     43 | 1612755 |      0 |      726 | (4,105) |           3 |       2306 |     24 |        |       | \xe90200001323373435232020200d2337343523
(1 row)

回到正題，我們首先看看index block 1的相關數(shù)據(jù)：

testdb=# select * from bt_page_stats('pk_t_index',1);
 blkno | type | live_items | dead_items | avg_item_size | page_size | free_size | btpo_prev | btpo_next | btpo | btpo_flags 
-------+------+------------+------------+---------------+-----------+-----------+-----------+-----------+------+------------
     1 | l    |        367 |          0 |            16 |      8192 |       808 |         0 |         2 |    0 |          1
(1 row)

testdb=# select * from bt_page_items('pk_t_index',1) limit 10;
 itemoffset |  ctid  | itemlen | nulls | vars |          data           
------------+--------+---------+-------+------+-------------------------
          1 | (2,53) |      16 | f     | f    | 7b 01 00 00 00 00 00 00
          2 | (0,1)  |      16 | f     | f    | 02 00 00 00 00 00 00 00
          3 | (0,2)  |      16 | f     | f    | 04 00 00 00 00 00 00 00
          4 | (0,3)  |      16 | f     | f    | 08 00 00 00 00 00 00 00
          5 | (0,4)  |      16 | f     | f    | 10 00 00 00 00 00 00 00
          6 | (0,6)  |      16 | f     | f    | 11 00 00 00 00 00 00 00
          7 | (0,5)  |      16 | f     | f    | 12 00 00 00 00 00 00 00
          8 | (0,8)  |      16 | f     | f    | 13 00 00 00 00 00 00 00
          9 | (0,9)  |      16 | f     | f    | 14 00 00 00 00 00 00 00
         10 | (0,10) |      16 | f     | f    | 15 00 00 00 00 00 00 00
(10 rows)

第1個block的Special space，其中type=l，表示leaf index block，btpo_flags=BTP_LEAF表示該block僅僅為leaf index block，block的index entries指向heap table。同時，這個block里面有367個items，右邊兄弟block號是2（btpo_next）。
值得注意到，index entries的第1個條目，是最大值\x017b，第2個條目才是最小值，接下來的條目是按順序存儲的其他值。源碼的README（src/backend/access/nbtree/README）里面有解釋：

On a page that is not rightmost in its tree level, the "high key" is
kept in the page's first item, and real data items start at item 2.
The link portion of the "high key" item goes unused.  A page that is
rightmost has no "high key", so data items start with the first item.
Putting the high key at the left, rather than the right, may seem odd,
but it avoids moving the high key as we add data items.

官方文檔也有相關解釋：

Note that the first item on any non-rightmost page (any page with a non-zero value in the btpo_next field) is the page's “high key”, meaning its data serves as an upper bound on all items appearing on the page, while its ctid field is meaningless. Also, on non-leaf pages, the first real data item (the first item that is not a high key) is a “minus infinity” item, with no actual value in its data field. Such an item does have a valid downlink in its ctid field, however.

下面我們再來看看index block 2&4：

testdb=# select * from bt_page_stats('pk_t_index',2);
 blkno | type | live_items | dead_items | avg_item_size | page_size | free_size | btpo_prev | btpo_next | btpo | btpo_flags 
-------+------+------------+------------+---------------+-----------+-----------+-----------+-----------+------+------------
     2 | l    |        367 |          0 |            16 |      8192 |       808 |         1 |         4 |    0 |          1
(1 row)

testdb=# select * from bt_page_items('pk_t_index',2) limit 10;
 itemoffset |  ctid   | itemlen | nulls | vars |          data           
------------+---------+---------+-------+------+-------------------------
          1 | (4,105) |      16 | f     | f    | e9 02 00 00 00 00 00 00
          2 | (2,53)  |      16 | f     | f    | 7b 01 00 00 00 00 00 00
          3 | (2,54)  |      16 | f     | f    | 7c 01 00 00 00 00 00 00
          4 | (2,55)  |      16 | f     | f    | 7d 01 00 00 00 00 00 00
          5 | (2,56)  |      16 | f     | f    | 7e 01 00 00 00 00 00 00
          6 | (2,57)  |      16 | f     | f    | 7f 01 00 00 00 00 00 00
          7 | (2,58)  |      16 | f     | f    | 80 01 00 00 00 00 00 00
          8 | (2,59)  |      16 | f     | f    | 81 01 00 00 00 00 00 00
          9 | (2,60)  |      16 | f     | f    | 82 01 00 00 00 00 00 00
         10 | (2,61)  |      16 | f     | f    | 83 01 00 00 00 00 00 00
(10 rows)

testdb=# select * from bt_page_stats('pk_t_index',4);
 blkno | type | live_items | dead_items | avg_item_size | page_size | free_size | btpo_prev | btpo_next | btpo | btpo_flags 
-------+------+------------+------------+---------------+-----------+-----------+-----------+-----------+------+------------
     4 | l    |        276 |          0 |            16 |      8192 |      2628 |         2 |         0 |    0 |          1
(1 row)

testdb=# select * from bt_page_items('pk_t_index',4) limit 10;
 itemoffset |  ctid   | itemlen | nulls | vars |          data           
------------+---------+---------+-------+------+-------------------------
          1 | (4,105) |      16 | f     | f    | e9 02 00 00 00 00 00 00
          2 | (4,106) |      16 | f     | f    | ea 02 00 00 00 00 00 00
          3 | (4,107) |      16 | f     | f    | eb 02 00 00 00 00 00 00
          4 | (4,108) |      16 | f     | f    | ec 02 00 00 00 00 00 00
          5 | (4,109) |      16 | f     | f    | ed 02 00 00 00 00 00 00
          6 | (4,110) |      16 | f     | f    | ee 02 00 00 00 00 00 00
          7 | (4,111) |      16 | f     | f    | ef 02 00 00 00 00 00 00
          8 | (4,112) |      16 | f     | f    | f0 02 00 00 00 00 00 00
          9 | (4,113) |      16 | f     | f    | f1 02 00 00 00 00 00 00
         10 | (4,114) |      16 | f     | f    | f2 02 00 00 00 00 00 00
(10 rows)

感謝各位的閱讀，以上就是“PostgreSQL數(shù)據(jù)庫B-Tree索引的物理存儲結構是怎樣的”的內容了，經(jīng)過本文的學習后，相信大家對PostgreSQL數(shù)據(jù)庫B-Tree索引的物理存儲結構是怎樣的這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！

網(wǎng)站欄目：PostgreSQL數(shù)據(jù)庫B-Tree索引的物理存儲結構是怎樣的
文章起源：http://jinyejixie.com/article10/psisgo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、、做網(wǎng)站、小程序開發(fā)、搜索引擎優(yōu)化、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)