大多數用戶在體驗數據庫時，接觸到的最早的sql語句就是count(*)，因此用戶判斷數據庫性能時通常也會通過count(*)進行比較。但在執行時通常會出現一個問題：對某個表做count(*)時需對全表數據進行掃描，當表中包含數據量較大的字段時，IO將會成為數據掃描的瓶頸。

數據掃描瓶頸有哪些優化方式？

針對上述問題，為解決全表掃描帶來的IO開銷的方案大致可分為三類：

第一類是減少掃描數據；

第二類是通過并行方式掃描數據；

第三類是通過預估值計算方式獲取結果。

根據上述三種方案，我們給出以下四種優化方式：

01

減少掃描數據

（1）使用列存

顧名思義，列存是按列存儲的。當使用count(*)查詢時，只需要掃描一列數據做count統計，而并非全表，這樣，IO開銷幾乎是行存的1/列數，即效率是行存的列數倍。在實際使用中，因為每列字段長度的原因，使用列存時count(*)效率往往要比這個值還要高得多。

（2）使用Index only scan

使用主鍵的Index only scan，count(*)僅需掃描主鍵的索引鏈表即可，不必掃描所有的數據塊，因此可大大減少IO開銷。

02

并行掃描數據

（1）MPP架構

使用MPP架構的好處是讓數據分布到各個計算節點上。這樣，在使用count(*)查詢時，每個計算節點都會去統計該節點的數據量，最終匯聚返回總的數據量，這種方式可以更好地利用CPU和磁盤達到并行掃描的效果，節省掃描時間。

03

預估值計算

（1）Hyperloglog

HyperLogLog算法來源于論文《HyperLogLog the analysis of a near-optimal cardinality estimation algorithm》，可以使用固定大小的字節計算任意大小的distinct value。由于HLL是概率計算算法，它依賴于數據的均勻分布，在使用時往往需要我們首先利用HLL對每個元素進行哈希，以使數據分布更加均勻。

因此，任何可以哈希的數據類型都可以使用HLL算法做統計估算，HLL算法在數據庫的估值統計計算方面起到了重要作用。

哪些產品能提供具體優化方案？

綜合上述4種優化方式，人大金倉悉心打造的MPP數據庫KADB具備以上所有特性方案，具體包括：

（1）列存

KADB支持可壓縮列存儲，壓縮比可達1:10。建表語句如下：

create table t_count(id uuid, num int) with

(appendonly=true,orientation=column,compresstype=zlib,compresslevel=5);

（2）Index only scan

KADB支持index only scan，執行計劃如下：

explain select count(*) from t_count ;

QUERY PLAN

------------------------------------------------------------------------------------------------------------------

Aggregate (cost=17403254.38..17403254.39 rows=1 width=8)

-> Gather Motion 8:1 (slice1; segments: 8) (cost=17403254.27..17403254.37 rows=1 width=8)

-> Aggregate (cost=17403254.27..17403254.28 rows=1 width=8)

-> Index Only Scan using idx_t_count_id on t_count (cost=0.19..17153253.65 rows=12500031 width=0)

（3）MPP架構

KADB是人大金倉基于Kingbase ES 單機數據庫打造的MPP數據庫，具有一切皆并行的特點。

（4）Hyperloglog

KADB集成了HLL插件。具體操作如下：

創建計數表，并插入1億條數據，id列重復值較少：

create table t_count(id uuid, num int);

--創建插入函數，id值為uuid，無重復值

create or replace function f_insert(i int) returns setof record as $$

select uuid_generate_v4(), generate_series(1,i);

$$ language sql;

--插入數據

insert into t_count select * from f_insert(100000000) as t(id uuid, num int);

創建HLL統計表，記錄唯一值：

create table daily_id_hll

as select

gp_hyperloglog_accum(id)

from

t_count;

最終通過HLL算法預估出t_count的條數

select gp_hyperloglog_get_estimate(gp_hyperloglog_accum) from daily_id_hll;

gp_hyperloglog_get_estimate

-----------------------------

99651193.2825577

(1 row)

誤差率在0.35%左右

select (100000000-99651193.2825577)/100000000;

?column?

------------------------

0.00348806717442300000

(1 row)

MPP數據庫KADB優化效果如何？

在此，我們導入1億條數據進行測試，數據總量大小為203GB，測試count(*)比對效率如下：

綜上總述，KADB具備以上所有優化方式的解決方案能力，可根據不同需求優化count(*)查詢。在用戶實際應用場景中，

面對實時性要求較高但準確度要求不太高的數據可視化服務，我們通常提供Hyperloglog優化方案；

面對實時性要求不太高但準確度要求高的統計服務，我們通常提供列存優化方案。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的判断字段长度大于某长度_判断数据库性能只能通过count(*)？No，这些优化方案了解一下！...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。