對於關係型數據庫而言,針對表的檢索,通常來講,創建合適的索引就能夠達到很好的檢索效果。(這裏不包含表設計的合理與否)sql
好比像狀態列這樣可選擇性很是低的值,該如何檢索? 其實這個已經不是關係型數據庫擅長的方面了。 可是若是出於歷史或者許多不可抗拒的緣由,數據庫
咱們還得在關係表中進行優化,該咋辦? 通常來講,就是創建靜態表。 可是靜態表也是多重多樣,該如何選擇? 我下面列舉幾個簡單的例子,固然了,優化
因爲我的的腦子尺度不夠大,有可能有些遺漏。設計
原始表。code
20 完條記錄, 大概36MB大小。blog
t_girl>create table rank_status (id integer not null, i_status varchar(3) not null);
第一種呢,就是創建LIST 表,這種表,能夠當作靜態表,也能夠當作原始表來作相關的更新。索引
只有2條記錄,大概720KB大小。get
t_girl>create table rank_status_extend (i_status varchar(3) not null, ids text);
咱們能夠對兩張表都作對應的更新操做。博客
插入一條記錄。string
t_girl> insert into rank_status values (222222,'yes'); Time: 4.397 ms t_girl>update rank_status_extend set ids = ids ||','||'222222' where i_status = 'yes'; Time: 43.725 ms
刪除一條記錄。
t_girl>delete from rank_status where i_status = 'yes' and id = 1; Time: 47.339 ms t_girl>update rank_status_extend set ids = replace(ids,',1,',',') where i_status = 'yes'; Time: 45.046 ms
更新一條記錄。
t_girl>update rank_status set id = 1000 where i_status = 'yes' and id = 20; Time: 65.834 ms t_girl>update rank_status_extend set ids = replace(ids,',20,',',1000,') where i_status = 'yes'; Time: 85.974 ms
咱們看到,在對錶的寫操做中,第二張表會比第一張慢一點。
其實咱們最主要的是關心讀操做。其實在讀上面仍是頗有優點的。
t_girl>select count(*) as total from rank_status where i_status = 'yes'; total ------- 99600 (1 row) Time: 86.563 ms t_girl>select length(ids) - length(replace(ids,',','')) + 1 as total from rank_status_extend where i_status = 'yes'; total ------- 99600 (1 row) Time: 35.762 ms t_girl>select string_agg(id::text,','),i_status from rank_status group by i_status; Time: 113.393 ms t_girl>select ids from rank_status_extend where i_status = 'yes'; Time: 2.447 ms
接下來第二種呢,就是分別創建兩張表, 可是這兩張表呢,少了存放狀態值的字段,因此在尺寸上小了不少。
t_girl>create table rank_status_yes (id int not null); 3552 kB t_girl>create table rank_status_no(id int not null); 3584 kB
固然這張表的檢索確定比原始表來的快,這裏,我就不演示了。
第三種呢,就是創建一張物化視圖,
t_girl>create materialized view mv_rank_status_yes as select * from rank_status where i_status = 'yes';
這種其實和第二種表很相似。只不過不一樣的是第二種表的維護須要人工來作,而這個視圖系統能夠維護。
本文出自 「上帝,我們不見不散!」 博客,請務必保留此出處http://yueliangdao0608.blog.51cto.com/397025/1366344