CMS不要讓MySQL為你流淚

那麼，MySQL的資料量到底能支援多少呢？其實MySQL單表的上限，主要與作業系統支援的最大檔案大小有關。我們來看一下官方的介紹。
1.4.4. MySQL表最大能達到多少
MySQL 3.22限制的表大小為4GB。由於在MySQL 3.23中使用了MyISAM儲存引擎，最大表尺寸增加到了65536TB（2567 – 1位元組）。由於允許的表尺寸更大，MySQL資料庫的最大有效表尺寸通常是由作業系統對檔案大小的限制決定的，而不是由MySQL內部限制決定的。
InnoDB儲存引擎將InnoDB表儲存在一個資料表空間內，該資料表空間可由數個檔案建立。這樣，表的大小就能超過單獨檔案的最大容量。資料表空間可包括原始磁碟分割，從而使得很大的表成為可能。資料表空間的最大容量為64TB。
在下面的表格中，列出了一些關於作業系統檔案大小限制的樣本。這僅是初步指南，並不是最終的。要想瞭解最新資訊，請參閱關於作業系統的文檔。
MySQL表最大能達到多少：http://dev.mysql.com/doc/refman/5.1/zh/introduction.html#table-size
事實上MySQL能承受的資料量的多少主要和資料表的結構有關，並不是一個固定的數值。表的結構簡單，則能承受的資料量相對比結構複雜時大些。
據D.V.B團隊以及Cmshelp團隊做CMS系統評測時的結果看來，MySQL單表一般在2千萬條記錄（4G）下能夠良好運行，經過資料庫的最佳化後5千萬條記錄（10G）下運行良好。那麼為什麼國內的某些CMS廠商還會把其產品自身負載差的責任推給MySQL呢？
這對於MySQL是不公平的，那些CMS廠商非但沒有把核心做好反而還在添加很多花哨的功能，最終導致其產品自身負載過低。他們並沒有針對自身負載效果作出相應的資料庫最佳化方案及標準，而是繼續保留著複雜的結構造成對MySQL的資源無休止的浪費，最終導致了其負載上的缺陷，於是他們便充分發揮中國人的傳統優勢——變通：避重就輕的採用了所謂的分表式儲存，雖然在一定程度上緩解了自身負載的缺陷，但是導致了網站後期維護以及資源上的浪費，這樣做是否是長久之計呢？雖然他們解決了眼前的問題，但以後呢？難道想無休止的分表來達到目的？MYLB.NET.CN博主追峰用一個不恰當的比喻來形容，MySQL中的的表就像一塊地，單表就相當於利用這塊地蓋高層建築充分利用達到高人員負載，但分表就相當於用這塊地蓋了一間平房，如果為了達到高人員負載的話那就需要另開地皮達到目的，但是我們要思考，是地不夠，還是他的能力不夠，如此做法讓人感到資源的浪費以及規劃的嚴重缺陷。那麼對於這樣的CMS系統，有誰敢用？難道為了達到讓其良好的運行而無休止的更換著伺服器配置嗎？況且大多情況下一台伺服器中不是只有這麼一個網站，那麼我們就要思考，我們的腰包是否是為了滿足這麼龐大的小CMS而生。
對於某些CMS廠商，MYLB.NET.CN博主追峰只能說其把負載問題推到MySQL身上的做法是極其不負責任的行為，分表的做法是避重就輕毫無責任感的做法，這不僅是對自己的不負責，更是對其使用者的不負責行為，難道你想用把責任推給MySQL以及分表的做法來掩飾自己產品的不足嗎？大錯特錯，你的這種做法只能愚弄那些剛接觸網站系統對於源碼以及資料庫不大瞭解的初級站長，但是對於大多圈內人士你是無法欺騙的；建議這類廠商還是把到各群和網站挑撥是非、誇大宣傳、詆毀他人的時間多多利用到如何改善自己產品讓使用者更好的獲益上；因為不管多初級的站長也會有成為老站長對源碼和資料庫駕輕就熟的時候，到那時看清你們本質的人會更多。
如此毫無責任感可言的CMS廠商會有多少使用者會忠實於你呢？對自己的產品都沒有責任感，那麼對待使用者還剩下多少呢？還有誰敢去選擇你們的產品呢？
這樣不思進取，說一套做一套了，吹噓自己的行為只能是把自己生生地捧得很高，但是別忘了，你的高度是自己吹上去的，使用者才是真正的評論者，到時候你們會摔到什麼程度那就要自己思考了。感謝大家對MYLB.NET.CN的支援。