原博文出自于：　　http://blog.fens.me/category/%E6%95%B0%E6%8D%AE%E5%BA%93/page/5/　　　　　　感謝！

?

?

?

Posted:

Feb 7, 2013

Tags:

MySQL

Comments:

0 Comments

[轉] select count(*)的思考

select count(*)的思考

原文：MYSQL性能調優與架構設計

?

舉例：

這里我們就拿一個看上去很簡單的功能來分析一下。

需求：一個論壇帖子總量的統計

附加要求：實時更新

?

在很多人看來，這個功能非常容易實現，不就是執行一條SELECT COUNT(*)的Query 就可以得到結果
了么？是的，確實只需要如此簡單的一個Query 就可以得到結果。但是，如果我們采用不是MyISAM 存儲
引擎，而是使用的Innodb 的存儲引擎，那么大家可以試想一下，如果存放帖子的表中已經有上千萬的帖
子的時候，執行這條Query 語句需要多少成本？恐怕再好的硬件設備，恐怕都不可能在10 秒之內完成一

次查詢吧。如果我們的訪問量再大一點，還有人覺得這是一件簡單的事情么？

?

既然這樣查詢不行，那我們是不是該專門為這個功能建一個表，就只有一個字段，一條記錄，就存
放這個統計量，每次有新的帖子產生的時候，都將這個值增加1，這樣我們每次都只需要查詢這個表就可
以得到結果了，這個效率肯定能夠滿足要求了。確實，查詢效率肯定能夠滿足要求，可是如果我們的系
統帖子產生很快，在高峰時期可能每秒就有幾十甚至上百個帖子新增操作的時候，恐怕這個統計表又要
成為大家的噩夢了。要么因為并發的問題造成統計結果的不準確，要么因為鎖資源爭用嚴重造成整體性

能的大幅度下降。

?

其實這里問題的焦點不應該是實現這個功能的技術細節，而是在于這個功能的附加要求“實時更
新”上面。當一個論壇的帖子數量很大了之后，到底有多少人會關注這個統計數據是否是實時變化的？
有多少人在乎這個數據在短時間內的不精確性？我想恐怕不會有人會傻傻的盯著這個統計數字并追究當
自己發了一個帖子然后回頭刷新頁面發現這個統計數字沒有加1 吧？即使明明白白的告訴用戶這個統計

數據是每過多長時間段更新一次，那有怎樣？難道會有很多用戶就此很不爽么？

?

只要去掉了這個“實時更新”的附加條件，我們就可以非常容易的實現這個功能了。就像之前所提
到的那樣，通過創建一個統計表，然后通過一個定時任務每隔一定時間段去更新一次里面的統計值，這

樣既可以解決統計值查詢的效率問題，又可以保證不影響新發貼的效率，一舉兩得。

?

實際上，在我們應用的系統中還有很多很多類似的功能點可以優化。如某些場合的列表頁面參與列

表的數據量達到一個數量級之后，完全可以不用準確的顯示這個列表總共有多少條信息，總共分了多少頁，
而只需要一個大概的估計值或者一個時間段之前的統計值。這樣就省略了我們的分頁程序需要在分

以前實時COUNT 出滿足條件的記錄數。

?

其實，在很多應用系統中，實時和準實時，精確與基本準確，在很多地方所帶來的性能消耗可能是
幾個性能的差別。在系統性能優化中，應該盡量分析出那些可以不實時和不完全精確的地方，作出一些
相應的調整，可能會給大家帶來意想不到的巨大性能提升。

轉載于:https://www.cnblogs.com/zlslch/p/6039931.html

總結

以上是生活随笔為你收集整理的转】MYSQL性能调优与架构设计之select count(*)的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

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