CMS不要讓MySQL為你流淚。本站提示廣大學習愛好者：（CMS不要讓MySQL為你流淚）文章只能為提供參考，不一定能成為您想要的結果。以下是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的支撐。
