count 淺析（2）

方案三：其他資料庫

其他資料庫的話首推 clickhouse，之前測試ch時發現執行count(*)速度非常快，截一張當時的PPT：

當然異構資料庫最大的問題就是要解決增量同步。mysql 同步至 CH，目前大多數的方案是使用python工具，該方案還不成熟，相信随着時間推移會有更好的方案，屆時很多 OLAP 或者 count(*) 業務都可以在 clickhouse 上進行。

小結

如果對行數這種實時性、響應性要求很高，而資料庫本身也已無法滿足，這時候才應該考慮去持久化計數。各種方案都是有利有弊，找到合适自己的才是最好的。

四. 關于查詢成本

在測試count性能時，想到了select操作會涉及查詢成本，于是特意把之前寫的有關查詢成本的内容貼了過來，希望可以幫到大家，也給自己做個知識點回顧。

執行計劃

再額外看下mysql的查詢成本，以一條sql為例：

SELECT
    *
FROM
    count_test 
WHERE
    var_col > 'var_co1123456'
AND insert_time < '2020-10-26 10:10:12'      

這條sql不出意外掃了全表，可能是由于用了 select * 需要回表，開銷較大。接下來改成索引覆寫的形式。

索引覆寫：

SELECT
    insert_time
FROM
    count_test 
WHERE
    var_col > 'var_co1123456'
AND insert_time < '2020-10-26 10:10:12'      

執行計劃顯示還是用了全表。

索引覆寫+強制索引：

使用 force index ，讓它強制使用時間索引：

執行計劃用到了時間索引。

查詢成本核算

核算公式：

cost = rows*0.2 + data_length/(1024*16)      

1. 全表查詢成本

199644 * 0.2 + 9977856 / (1024 * 16) = 40,537.8

代入公式可以算出，全表的成本約為 40537.8

2. 各索引查詢成本

通過 optimizer_trace 方式檢視：

SET optimizer_trace="enabled=on";

SELECT insert_time FROM count_test WHERE var_col > 'var_co1123456' AND insert_time < '2020-10-26 10:10:12';

SELECT * FROM information_schema.OPTIMIZER_TRACE;

SET optimizer_trace="enabled=off";      

然後看下走索引的預估成本

optimizer_trace 下全表查詢的預估成本：

40540 和我們之前計算的 40537.8 差不多，這個值要遠小于走索引的成本。

是以 mysql 在執行此 sql 的時候會使用全表掃描，都是基于執行成本來判斷的。

全文完。

Enjoy MySQL :