索引優(yōu)化
AnalyticDB PostgreSQL版數(shù)據(jù)庫(kù)支持B-Tree、Bitmap，BRIN，GiST和GIN索引，不支持Hash索引。每一種索引類型都使用一種不同的算法，它們最適合的查詢類型也不同。 B-Tree索引適合于最常見的情況并且是默認(rèn)的索引類型。
AnalyticDB PostgreSQL版Serverless實(shí)例僅支持創(chuàng)建B-Tree類型索引。
在大部分傳統(tǒng)的TP型數(shù)據(jù)庫(kù)中，索引可以極大的提高數(shù)據(jù)的訪問(wèn)效率。但是在類似與AnalyticDB PostgreSQL版這樣的分布式數(shù)據(jù)庫(kù)中，應(yīng)該謹(jǐn)慎的選擇索引的使用。在大部分場(chǎng)景下，AnalyticDB PostgreSQL版更適合快速的順序掃描，或者結(jié)合稀疏索引來(lái)進(jìn)行減少數(shù)據(jù)的I/O操作。AnalyticDB PostgreSQL版會(huì)將數(shù)據(jù)盡量均勻地分布在所有的計(jì)算節(jié)點(diǎn)上，因此，在節(jié)點(diǎn)足夠多的情況下，每一個(gè)計(jì)算節(jié)點(diǎn)只會(huì)掃描屬于自己的一小部分?jǐn)?shù)據(jù)。并且對(duì)于BI報(bào)表類查詢，通常會(huì)返回很大的數(shù)據(jù)集，使用索引在這種場(chǎng)景并不一定有加速查詢的效果。
在使用AnalyticDB PostgreSQL版時(shí)，首先應(yīng)該嘗試在沒有增加任何索引的情況下執(zhí)行您的查詢。索引通常都是更適合于TP場(chǎng)景的，只返回一條記錄或者返回極少量數(shù)據(jù)集的數(shù)據(jù)。使用索引也會(huì)給數(shù)據(jù)庫(kù)帶來(lái)一些額外的開銷，比如需要更多的存儲(chǔ)，以及數(shù)據(jù)的寫放大，還有包括在進(jìn)行數(shù)據(jù)update時(shí)的索引維護(hù)工作的開銷。因此我們需要確保我們?yōu)楸碓黾拥乃饕鄬?duì)于全表掃描，能夠切實(shí)、有效地提高了查詢效率，否則寧愿不建索引。
只有索引鍵的列與AnalyticDB PostgreSQL版分布鍵相同（或者是其超集）時(shí)，AnalyticDB PostgreSQL版數(shù)據(jù)庫(kù)才允許唯一索引。 在追加優(yōu)化表上不支持唯一索引。在分區(qū)表上，唯一索引無(wú)法在一個(gè)分區(qū)表的所有子表分區(qū)之間被實(shí)施。唯一索引只能在一個(gè)分區(qū)內(nèi)實(shí)施。
在當(dāng)您想要建索引時(shí)應(yīng)該需要考慮以下幾點(diǎn)：
您的查詢負(fù)載： 索引可以有效地提高返回單條或者小數(shù)據(jù)結(jié)果集的查詢，比如TP類的查詢。
壓縮表或者適合使用稀疏索引的范圍查詢： 索引可以提高壓縮的AO/AOCS表的查詢效率，尤其是在進(jìn)行范圍查詢時(shí)使用稀疏索引，可以有效地避免加載無(wú)效的數(shù)據(jù)，從而優(yōu)化I/O效率。同理，更少的數(shù)據(jù)加載意味著更少的數(shù)據(jù)解壓縮，可以有效地降低解壓操作CPU的使用。
避免對(duì)頻繁更新的列建索引：對(duì)于數(shù)據(jù)頻繁更新的列，如果數(shù)據(jù)頻繁更新，索引也會(huì)頻繁更新，這會(huì)極大的降低數(shù)據(jù)更新的性能。
只對(duì)高選擇率的列建B-Tree索引： 索引選擇率是構(gòu)建索引時(shí)選擇什么索引類型的重要指標(biāo)，B-Tree索引只推薦使用在選擇率非常高的列上。比如您的表有1000行數(shù)據(jù)，需要建索引的列有800個(gè)distinct的值，那么這一列索引選擇率就是800/1000=0.8,這種場(chǎng)景就很適合建B-Tree索引。如果您建索引的列的值是唯一的，建議選擇B-Tree索引。
選擇率低時(shí)考慮使用Bitmap索引：AnalyticDB PostgreSQL版支持Bitmap索引類型，其非常適合于distinct值范圍在1000-100,000內(nèi)的類的索引。尤其是結(jié)合排序鍵對(duì)數(shù)據(jù)聚集，可以達(dá)到用很小的索引達(dá)到很驚艷的索引加速效果。
考慮對(duì)經(jīng)常進(jìn)行join操作的列建索引：在執(zhí)行join時(shí)使用索引可能會(huì)有更好的執(zhí)行計(jì)劃。
對(duì)于經(jīng)常做限定條件查詢的列建索引：對(duì)于經(jīng)常更在WHERE后面做限定條件的列，可以考慮建索引。
防止對(duì)同一個(gè)列建多個(gè)索引：對(duì)于同一個(gè)列建同一類前綴索引是沒有意義的，并且會(huì)在寫入和更新時(shí)增加額外的開銷。
結(jié)合排序鍵或者Cluster功能加速索引效率：大部分索引的效率都會(huì)極大的受到數(shù)據(jù)物理分布的影響，尤其是BRIN索引和稀疏索引。因此，根據(jù)索引的字段組織合適的數(shù)據(jù)物理分布可以有效地提高索引的性能。您可以使用排序鍵結(jié)合組合排序和多維排序改善數(shù)據(jù)的物理分布。同時(shí)對(duì)于行存表如果建立的是B-Tree類型的索引，可以考慮使用Cluster進(jìn)行物理排序。
大數(shù)據(jù)集場(chǎng)景下優(yōu)先考慮稀疏索引：如果您的數(shù)據(jù)量非常地大，并且您的查詢限定條件為<、<=、=、>=、>，需要從大數(shù)據(jù)量的表中取出少于50%的數(shù)據(jù)，那么使用稀疏索引（BRIN Index或者AOCS表的metascan）可以極大地減少無(wú)效數(shù)據(jù)的加載。
： 對(duì)于載入大量數(shù)據(jù)到一個(gè)表中，請(qǐng)考慮先刪掉索引并且在數(shù)據(jù)裝載完成后重建它們。這常常比更新索引更快。
避免在頻繁更新的表上建Bitmap索引： Bitmap索引最適合用戶只查詢數(shù)據(jù)而不更新數(shù)據(jù)的數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用，不適合有大量并發(fā)事務(wù)修改數(shù)據(jù)的OLTP應(yīng)用。
合理使用表達(dá)式索引：索引列不必只是表的一列，而是可以是從表的一列或多列計(jì)算的函數(shù)或標(biāo)量表達(dá)式。 此功能對(duì)于根據(jù)計(jì)算結(jié)果快速訪問(wèn)表非常有用。比如查詢
SELECT * FROM people WHERE (first_name || ' ' || last_name) = 'John Smith';可以收益于表達(dá)式索引CREATE INDEX people_names ON people ((first_name || ' ' || last_name));。