SELECT content FROM test1 WHERE id = constant;
若是數據很大的時候,數據庫會一條一條的查,效率很低
CREATE INDEX test_id_index ON test1 (id);
在一個很大的表建立索引須要消耗很長時間,postgreSQL容許建立索引的時候查詢數據,可是插入,修改,刪除的時候必須等到索引建立完後才能夠執行。
建立索引後,它必須和表保持同步,這些操做會增長數據庫的負荷,所以咱們須要刪除不用或者沒必要要的索引。
postgreSQL提供了好幾種類型,B-tree Hash GiST SP-GiST 和 GIN
在使用create index語句時,會建立B-tree索引,這種索引適用大部分狀況。
B-tree適合處理那些可以按照順序的數據之上的等於和範圍查詢
Hash索引只能處理比較簡單的等於比較,當一個索引列涉及到使用=操做符進行比較的時候,查詢規劃器會考慮使用Hash索引,建立Hash索引語句:
CREATE INDEX name ON table USING hash (column);
Hash索引操做目前沒有記錄WAL日誌,所以數據庫崩潰後若是有未寫入的改變,可能須要用REINDEX重建Hash索引。另外,對hash索引的改變在初始的基礎備份後不會被實施基於流或者基於文件的複製,因此對於隨後使用它們的查詢會給出錯誤的回覆。所以這些緣由,因此並不鼓勵使用Hash索引。
SELECT name FROM test2 WHERE major = constant AND minor = constant;
CREATE INDEX test2_mm_idx ON test2 (major,minor);
目前只有B-tree GiST 和 GIN支持多字段索引
建立索引時,能夠經過包含選項ASC , DESC , NULLS FIRST 和 / 或NULLS LAST調整B-tree索引的順序
CREATE INDEX test2_info_nulls_low ON test2 (info NULLS FIRST);
CREATE INDEX test3_desc_index ON test3 (id DESC NULLS LAST);
假設在(a,b)上建立一個索引,那麼相似where a = 5 and b = 4的條件可使用索引的,可是where a = 5 or b = 10的條件不能直接使用索引
若是在查詢的時候,涉及到x,有時涉及到y,有時涉及到x,y,這種狀況就能夠在x和y上建立兩個獨立的索引
索引還能夠用於強迫字段數值的惟一性,或者是多個字段組合值的惟一性
CREATE UNIQUE INDEX name ON table (column [,...]);
若是索引聲明爲惟一的,那麼就不容許出現多個索引值相同的行,null被認爲互不相等,一個多字段惟一索引只在多行數據裏全部被索引字段都相等時才拒絕
若是一個聲明瞭惟一約束或者主鍵,那麼postgreSQL自動在組成主鍵或惟一約束的字段上建立惟一索引(多是多字段索引),以強制執行這些約束
給表增長惟一約束比較好的辦法是ALTER TABLE ... ADD CONSTRAINT.用索引強制執行惟一約束應該認爲是一個實現細節,而不該該直接訪問。不過,咱們應該知道沒有必要再惟一字段上創建索引,那樣作只會和自動建立的索引重複。