目錄是否需要實時更新物化視圖工具（Flexviews）計數(shù)表總結

緩存型數(shù)據(jù)表通常在統(tǒng)計數(shù)據(jù)時會經常用到，因此也會叫統(tǒng)計性數(shù)據(jù)。舉個例子來說，對于員工、部門數(shù)據(jù)表而言，我們可能會需要查詢一個部門下有多少員工。這時候有三種方式實現(xiàn)：

在部門下增加一個員工數(shù)量的字段，每次對員工進行增、改、刪操作時都需要同步更新員工數(shù)量（如果員工換部門，則需要更新多個部門的員工數(shù)量）。這種方式能夠保證實時性，但是卻很低效。對于如果是操作不頻繁時是沒問題的，假設相當頻繁，就意味著每次都需要操作兩張表，而且業(yè)務代碼都需要做埋點處理，將統(tǒng)計業(yè)務和普通業(yè)務深度耦合在一起了。 每次查詢的時候，從員工表中執(zhí)行 SUM 函數(shù)，獲取該部門的員工數(shù)。這種方式避免了埋點，但是每次都需要去員工數(shù)據(jù)表求和，如果員工數(shù)據(jù)量大的話會很低效。 新建一張統(tǒng)計表，每隔一定時間從員工表中匯總每個部門的人員數(shù)量。這種定時抽取數(shù)據(jù)的方式會犧牲一定的實時性，但降低了代碼的耦合，由于部門不會太多，這張表的大小是可預測的，也提高了數(shù)據(jù)訪問的效率。這種方式即緩存型數(shù)據(jù)表。

以掘金的手機端個人中心為例，為展示每個用戶的關注人數(shù)、關注者和掘力值，不可能每次查詢都去做一次 SUM，這意味著需要做多張表的 SUM 操作，效率會很低，而且掘力值的計算還涉及到更為復雜的計算方法（與文章的瀏覽量和點贊數(shù)有關）。因此，可以猜測一下大致的表設計，這樣在查詢用戶個人主頁信息的時候只需要從這一張表就可以讀取到所有數(shù)據(jù)了。

CREATE t_user_summay ( id INT PRIMARY KEY, user_id BIGINT(20), focused_user_cnt INT, followed_user_cnt INT, user_value INT, user_level ENUM(’Lv1’, ’Lv2’, ..., ’Lv8’), created_time DATETIME, updated_time DATETIME,);

是否需要實時更新

在實際應用過程中，統(tǒng)計表有兩種方式，一種是實時更新，一種是周期性的重建數(shù)據(jù)。兩種方式有利有弊，實時更新保證了查詢數(shù)據(jù)的即時性，但是會犧牲性能，并且要求代碼埋點，而且由于數(shù)據(jù)更新是沒有規(guī)律的，可能產生碎片。周期性的重建數(shù)據(jù)犧牲了實時性，如果說大部分數(shù)據(jù)都不變的話會帶來不必要的統(tǒng)計計算，但如果數(shù)據(jù)經常變動，那周期性地重建數(shù)據(jù)顯然會更高效而且避免了埋點的情況。當然，避免應用程序的埋點也可以通過觸發(fā)器來完成，可以參考//www.jb51.net/article/213062.htm

物化視圖工具（Flexviews）

在 MySQL 中，有一個 Flexviews 的開源工具用于從數(shù)據(jù)庫的binlog 中提取數(shù)據(jù)完成數(shù)據(jù)統(tǒng)計。有點類似與視圖，但與視圖所不同的是，F(xiàn)lexviews 產生的數(shù)據(jù)表是物理表，這也是為什么稱之為物化視圖的原因。而且，F(xiàn)lexviews 還支持增量更新和全量更新。推薦使用增量更新，以避免所有行的統(tǒng)計數(shù)據(jù)都需要重建的情況。增量更新會檢查哪些數(shù)據(jù)行數(shù)據(jù)發(fā)生了改變，再執(zhí)行更新操作，相比全量更新而言性能會更高。但為了檢測數(shù)據(jù)改變，需要引入一個視圖記錄數(shù)據(jù)行的變化日志。

計數(shù)表

在實際開發(fā)中，我們經常會需要對一些操作進行計數(shù)，比如文章的閱讀數(shù)、點贊數(shù)。如果將計數(shù)值放入同一張表很可能在更新的時候出現(xiàn)并發(fā)問題。使用獨立的計數(shù)表可以避免查詢緩存失效問題并使用一些更高級的技巧。例如統(tǒng)計文章的閱讀數(shù)、點贊數(shù)的數(shù)據(jù)表：

CREATE TABLE t_article_counter ( article_id INT PRIMARY KEY, read_cnt INT UNSIGNED NOT NULL, praise_cnt INT UNSIGNED NOT NULL);

在更新閱讀數(shù)的時候，可以使用 MySQL 的內置加1操作：

UPDATE t_article_counter SET read_cnt = read_cnt + 1WHERE article_id = 1;

這種方式可以使得操作是單行的，對事物而言是互斥的，因此會將事務序列化處理避免并發(fā)問題。但是卻會影響并發(fā)請求量?？梢詫ξ恼略黾佣鄠€插槽來提高并發(fā)量。

CREATE TABLE t_article_counter ( id INT NOT NULL PRIMARY KEY, slot TINYINT UNSIGNED, article_id INT, read_cnt INT UNSIGNED NOT NULL, praise_cnt INT UNSIGNED NOT NULL, INDEX(article_id));

這時可以創(chuàng)建100個插槽初始化數(shù)據(jù)，在更新的時候可以這樣操作：

UPDATE t_article_counterSET read_cnt = read_cnt + 1 WHERE slot = RAND() * 100 AND article_id = 1;

獲取某篇文章的總閱讀數(shù)時，需要使用一個 SUM 操作：

SELECT SUM(read_cnt) FROM t_article_counterWHERE article_id = 1;

這種方式實際上是空間換時間，提高了并發(fā)量。

總結

本篇介紹了如何設計統(tǒng)計數(shù)據(jù)表，關鍵的核心在于業(yè)務類型。對于更新頻率低、數(shù)據(jù)量小的表使用實時同步或者直接 SUM 求和問題都不大。而對于大數(shù)據(jù)表，高頻率的更新的情況，則可以使用獨立的統(tǒng)計表。同時，若存在高并發(fā)的情況，統(tǒng)計表中可以考慮每項主體增加多個插槽的方式提高并發(fā)量。如果是周期性地同步數(shù)據(jù)，也可以使用 Flexviews 物化視圖插件實現(xiàn)。

以上就是MySQL 如何設計統(tǒng)計數(shù)據(jù)表的詳細內容，更多關于MySQL 設計統(tǒng)計數(shù)據(jù)表的資料請關注好吧啦網其它相關文章！