點陣圖與ERP場景

   經常遇到這種場景，select count(*) from t where t.col='XXX'  其實col列就2-5種型別，這種通常來說建立一個索引的效果不好。但是去找開發談的時候，開發說這就是2B的企業使用者場景。一共就2-3家公司，又不是2C的有上萬個使用者，每個使用者看自己的資料。這裡每家公司已經是隻看自己的資料了，就這樣。

     看上去無解了，每次就是要實時計算。但是其實還是有辦法的。比如我建立一個簡單的表create table wt (id int,org varchar2(10),name varchar2(10))，按照場景寫入幾千萬資料進去，但是ORG只有兩個值A和B，大約各佔50%的資料量。一般來說這樣情況下建立B-TREE索引是無效的。所以要改變方式：這裡建立點陣圖索引。給那種區分度很低的場景。可以看到點陣圖索引加持下，大約2000萬資料20毫秒分組統計好。

如果查詢明細帶上分頁：

MySQL目前不支援這種，所以不少ERP場景使用MySQL其實是不恰當的。正如MySQL首席架構師王偉說：MySQL定位6個字：輕量，快進快出。

我覺得這樣說很清楚，每種資料庫都有擅長的。其實就像這個點陣圖，他也有他的限制。就是這裡的值是幾乎不改或者就是不改的。比如說性別，比如我們的行政區。而如果說是把經常要改的狀態設定成點陣圖就非常有問題了。

在這種所謂的統計聚合中，點陣圖其實是把要統計的已經算好了。所以別說2000萬，就是20億這樣分組，也是毫秒級別的。我也試過2億資料分100組，1秒就夠了。

如何設計如何實現，會讓你收益很大，有時候已有的技術足以應付很多大資料場景。其實很多時候，計算落地遠勝於實時計算。感興趣的話看看我公眾號斐波拉契數列的那個文章。往前翻使勁翻。

我本想看看PG中的點陣圖索引，查了資料沒查到。問了高手，原來是 Pg沒有點陣圖索引的， 只有bitmap scan。最後看了演示和我最初的想法不一樣。

可能還有其他資料庫也支援的，我暫時還不知道。正確使用MySQL和正確使用其他資料庫都會有一個較好的結果。