現在有很多的項目，對計數器的實現甚是隨意，比如在實現網站文章點擊數的時候，是這麼設計數據表的，如：”article_id, article_name, article_content, article_author, article_view……在article_view中記錄該文章的浏覽量。詐一看似乎沒有問題。對於小站，比如本博客，就是這麼做的，因為小菜的博客難道會涉及並發問題嗎?答案顯而易見，一天沒多少IP，而且以後不會很大。
言歸正傳，對文章資訊類為主的項目，在浏覽一個頁面的時候不但要進行大量的查(查詢上文的記錄，已經所屬分類的名字、熱門文章資訊評論、TAG等)，還要進行寫操作(更新浏覽數點擊數)。把文章的詳細內容和計數器放在一張表盡管對開發很方便，但是會造成數據庫的壓力過大(不然為什麼大項目都要分庫分表呢)。
那麼，分兩張表存放就好了麼?一張表存文章詳細信息，另一張表單獨存計數器。
代碼如下:
CREATE TABLE `article_view`(
`article_id` int(11) NOT NULL,
`view` int(11) NOT NULL,
PRIMARY KEY (`article_id`)
)ENGINE=InnoDB;
這種方式，雖然分擔了文章表的壓力，但是每當有一個進程請求更新的時候，都會產生全局的互斥鎖，只能串行，不能並行。在高並發下會有較長的等待時間。
另一種比較好的辦法是對每一個文章的計數器不是一行，而是多行，比如吧，一百行。每次隨機更新其中一行，該文章的浏覽數就是所有行的和。
代碼如下:
CREATE TABLE `article_view`(
`article_id` int(11) NOT NULL,
`pond` tinyint(4) NOT NULL COMMENT '池子，就是用來隨機用的',
`view` int(11) NOT NULL,
PRIMARY KEY (`article_id`,`pond`)
)ENGINE=InnoDB;
小訪問量的隨機池子100個肯定多了，三五個足矣。每次訪問的時候，隨機一個數字(1-100)作為pond，如何該pond存在則更新view+1，否則插入，view=1。借助DUPLICATE KEY，不然在程序裡是實現得先SELECT，判斷一下再INSERT或者UPDATE。
代碼如下:
INSERT INTO `article_view` (`article_id`, `pond`, `view`) VALUES (`123`, RAND()*100, 1) ON DUPLICATE KEY UPDATE `view`=`view`+1
獲取指定文章的總訪問量的時候：
代碼如下:
SELECT SUM(`view`) FROM `article_view` WHERE `article_id`='123'
PS：凡事都是雙刃劍。為了更快的讀我們通常要犧牲一些東西。在讀比較多的表要加快讀的速度，在寫較多的表要加快寫的速度。各自權衡。在加快讀的速度的時候，我們犧牲的並不僅僅是寫的性能，還有開發成本，開發變的更復雜，維護成本等。所以並不是讀的速度越快越好，需要找一個平衡點。
