CMS不要讓MySQL為你流淚
更新時間：2008年12月12日 11:57:11 作者：
MySQL是中小型網站普遍使用的數(shù)據(jù)庫之一，然而，很多人并不清楚MySQL到底能支持多大的數(shù)據(jù)量，再加上某些國內CMS廠商把數(shù)據(jù)承載量的責任推給它，導致很多不了解MySQL的站長對它產生了很多誤解
那么，MySQL的數(shù)據(jù)量到底能支持多少呢？其實MySQL單表的上限，主要與操作系統(tǒng)支持的最大文件大小有關。我們來看一下官方的介紹。
1.4.4. MySQL表最大能達到多少
MySQL 3.22限制的表大小為4GB。由于在MySQL 3.23中使用了MyISAM存儲引擎，最大表尺寸增加到了65536TB（2567 – 1字節(jié)）。由于允許的表尺寸更大，MySQL數(shù)據(jù)庫的最大有效表尺寸通常是由操作系統(tǒng)對文件大小的限制決定的，而不是由MySQL內部限制決定的。
InnoDB存儲引擎將InnoDB表保存在一個表空間內，該表空間可由數(shù)個文件創(chuàng)建。這樣，表的大小就能超過單獨文件的最大容量。表空間可包括原始磁盤分區(qū)，從而使得很大的表成為可能。表空間的最大容量為64TB。
在下面的表格中，列出了一些關于操作系統(tǒng)文件大小限制的示例。這僅是初步指南，并不是最終的。要想了解最新信息，請參閱關于操作系統(tǒng)的文檔。
MySQL表最大能達到多少：http://dev.mysql.com/doc/refman/5.1/zh/introduction.html#table-size
事實上MySQL能承受的數(shù)據(jù)量的多少主要和數(shù)據(jù)表的結構有關，并不是一個固定的數(shù)值。表的結構簡單，則能承受的數(shù)據(jù)量相對比結構復雜時大些。
據(jù)D.V.B團隊以及Cmshelp團隊做CMS系統(tǒng)評測時的結果看來，MySQL單表一般在2千萬條記錄（4G）下能夠良好運行，經過數(shù)據(jù)庫的優(yōu)化后5千萬條記錄（10G）下運行良好。那么為什么國內的某些CMS廠商還會把其產品自身負載差的責任推給MySQL呢？
這對于MySQL是不公平的，那些CMS廠商非但沒有把內核做好反而還在添加很多花哨的功能，最終導致其產品自身負載過低。他們并沒有針對自身負載效果作出相應的數(shù)據(jù)庫優(yōu)化方案及標準，而是繼續(xù)保留著復雜的結構造成對MySQL的資源無休止的浪費，最終導致了其負載上的缺陷，于是他們便充分發(fā)揮中國人的傳統(tǒng)優(yōu)勢——變通：避重就輕的采用了所謂的分表式存儲，雖然在一定程度上緩解了自身負載的缺陷，但是導致了網站后期維護以及資源上的浪費，這樣做是否是長久之計呢？雖然他們解決了眼前的問題，但以后呢？難道想無休止的分表來達到目的？MYLB.NET.CN博主追峰用一個不恰當?shù)谋扔鱽硇稳?，MySQL中的的表就像一塊地，單表就相當于利用這塊地蓋高層建筑充分利用達到高人員負載，但分表就相當于用這塊地蓋了一間平房，如果為了達到高人員負載的話那就需要另開地皮達到目的，但是我們要思考，是地不夠，還是他的能力不夠，如此做法讓人感到資源的浪費以及規(guī)劃的嚴重缺陷。那么對于這樣的CMS系統(tǒng)，有誰敢用？難道為了達到讓其良好的運行而無休止的更換著服務器配置么？況且大多情況下一臺服務器中不是只有這么一個網站，那么我們就要思考，我們的腰包是否是為了滿足這么龐大的小CMS而生。
對于某些CMS廠商，MYLB.NET.CN博主追峰只能說其把負載問題推到MySQL身上的做法是極其不負責任的行為，分表的做法是避重就輕毫無責任感的做法，這不僅是對自己的不負責，更是對其用戶的不負責行為，難道你想用把責任推給MySQL以及分表的做法來掩飾自己產品的不足么？大錯特錯，你的這種做法只能愚弄那些剛接觸網站系統(tǒng)對于源碼以及數(shù)據(jù)庫不大了解的初級站長，但是對于大多圈內人士你是無法欺騙的；建議這類廠商還是把到各群和網站挑撥是非、夸大宣傳、詆毀他人的時間多多利用到如何改善自己產品讓用戶更好的獲益上；因為不管多初級的站長也會有成為老站長對源碼和數(shù)據(jù)庫駕輕就熟的時候，到那時看清你們本質的人會更多。
如此毫無責任感可言的CMS廠商會有多少用戶會忠實于你呢？對自己的產品都沒有責任感，那么對待用戶還剩下多少呢？還有誰敢去選擇你們的產品呢？
這樣不思進取，說一套做一套了，吹噓自己的行為只能是把自己生生地捧得很高，但是別忘了，你的高度是自己吹上去的，用戶才是真正的評論者，到時候你們會摔到什么程度那就要自己思考了。感謝大家對MYLB.NET.CN的支持。
1.4.4. MySQL表最大能達到多少
MySQL 3.22限制的表大小為4GB。由于在MySQL 3.23中使用了MyISAM存儲引擎，最大表尺寸增加到了65536TB（2567 – 1字節(jié)）。由于允許的表尺寸更大，MySQL數(shù)據(jù)庫的最大有效表尺寸通常是由操作系統(tǒng)對文件大小的限制決定的，而不是由MySQL內部限制決定的。
InnoDB存儲引擎將InnoDB表保存在一個表空間內，該表空間可由數(shù)個文件創(chuàng)建。這樣，表的大小就能超過單獨文件的最大容量。表空間可包括原始磁盤分區(qū)，從而使得很大的表成為可能。表空間的最大容量為64TB。
在下面的表格中，列出了一些關于操作系統(tǒng)文件大小限制的示例。這僅是初步指南，并不是最終的。要想了解最新信息，請參閱關于操作系統(tǒng)的文檔。
MySQL表最大能達到多少：http://dev.mysql.com/doc/refman/5.1/zh/introduction.html#table-size
事實上MySQL能承受的數(shù)據(jù)量的多少主要和數(shù)據(jù)表的結構有關，并不是一個固定的數(shù)值。表的結構簡單，則能承受的數(shù)據(jù)量相對比結構復雜時大些。
據(jù)D.V.B團隊以及Cmshelp團隊做CMS系統(tǒng)評測時的結果看來，MySQL單表一般在2千萬條記錄（4G）下能夠良好運行，經過數(shù)據(jù)庫的優(yōu)化后5千萬條記錄（10G）下運行良好。那么為什么國內的某些CMS廠商還會把其產品自身負載差的責任推給MySQL呢？
這對于MySQL是不公平的，那些CMS廠商非但沒有把內核做好反而還在添加很多花哨的功能，最終導致其產品自身負載過低。他們并沒有針對自身負載效果作出相應的數(shù)據(jù)庫優(yōu)化方案及標準，而是繼續(xù)保留著復雜的結構造成對MySQL的資源無休止的浪費，最終導致了其負載上的缺陷，于是他們便充分發(fā)揮中國人的傳統(tǒng)優(yōu)勢——變通：避重就輕的采用了所謂的分表式存儲，雖然在一定程度上緩解了自身負載的缺陷，但是導致了網站后期維護以及資源上的浪費，這樣做是否是長久之計呢？雖然他們解決了眼前的問題，但以后呢？難道想無休止的分表來達到目的？MYLB.NET.CN博主追峰用一個不恰當?shù)谋扔鱽硇稳?，MySQL中的的表就像一塊地，單表就相當于利用這塊地蓋高層建筑充分利用達到高人員負載，但分表就相當于用這塊地蓋了一間平房，如果為了達到高人員負載的話那就需要另開地皮達到目的，但是我們要思考，是地不夠，還是他的能力不夠，如此做法讓人感到資源的浪費以及規(guī)劃的嚴重缺陷。那么對于這樣的CMS系統(tǒng)，有誰敢用？難道為了達到讓其良好的運行而無休止的更換著服務器配置么？況且大多情況下一臺服務器中不是只有這么一個網站，那么我們就要思考，我們的腰包是否是為了滿足這么龐大的小CMS而生。
對于某些CMS廠商，MYLB.NET.CN博主追峰只能說其把負載問題推到MySQL身上的做法是極其不負責任的行為，分表的做法是避重就輕毫無責任感的做法，這不僅是對自己的不負責，更是對其用戶的不負責行為，難道你想用把責任推給MySQL以及分表的做法來掩飾自己產品的不足么？大錯特錯，你的這種做法只能愚弄那些剛接觸網站系統(tǒng)對于源碼以及數(shù)據(jù)庫不大了解的初級站長，但是對于大多圈內人士你是無法欺騙的；建議這類廠商還是把到各群和網站挑撥是非、夸大宣傳、詆毀他人的時間多多利用到如何改善自己產品讓用戶更好的獲益上；因為不管多初級的站長也會有成為老站長對源碼和數(shù)據(jù)庫駕輕就熟的時候，到那時看清你們本質的人會更多。
如此毫無責任感可言的CMS廠商會有多少用戶會忠實于你呢？對自己的產品都沒有責任感，那么對待用戶還剩下多少呢？還有誰敢去選擇你們的產品呢？
這樣不思進取，說一套做一套了，吹噓自己的行為只能是把自己生生地捧得很高，但是別忘了，你的高度是自己吹上去的，用戶才是真正的評論者，到時候你們會摔到什么程度那就要自己思考了。感謝大家對MYLB.NET.CN的支持。
相關文章
在數(shù)據(jù)庫中?事務(transaction)?可以把多個SQL給打包到一起,?即將多個SQL語句變成一個整體,?也就是說一個事務中的所有操作要么全部成功執(zhí)行,?要么完全不執(zhí)行.本文主要來和大家聊聊事務的使用，需要的可以參考一下2022-12-12
mysql服務性能優(yōu)化—my.cnf_my.ini配置說明詳解(16G內存)
這篇文章主要介紹了mysql服務性能優(yōu)化—my.cnf_my.ini配置說明詳解(16G內存),需要的朋友可以參考下2016-05-05
在本篇文章里小編給大家整理的是關于詳解Mysql查詢條件中字符串尾部有空格也能匹配上的問題，需要的朋友們可以參考下2020-02-02
emoji表情在我們日常開發(fā)中經常會遇到，但是最近在mysql中插入emoji表情遇到了問題，通過查找相關的資料終于解決了，所以將這次解決的過程分享出來，這篇文章主要就給大家介紹了MySQL插入emoji表情失敗問題的解決方法，需要的朋友可以參考。2017-05-05
本篇文章主要介紹了MySQL中的 數(shù)據(jù)庫備份詳解，有需要的朋友可以借鑒參考下，希望可以有所幫助，祝大家多多進步，早日升職加薪2021-09-09
本文主要介紹了搭建Mysql視圖可視化操作,文中通過圖文介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2023-10-10
SQL實現(xiàn)LeetCode(196.刪除重復郵箱)
這篇文章主要介紹了SQL實現(xiàn)LeetCode(196.刪除重復郵箱),本篇文章通過簡要的案例,講解了該項技術的了解與使用,以下就是詳細內容,需要的朋友可以參考下2021-08-08
本篇文章是對EXPLAIN的使用進行了詳細的分析介紹，需要的朋友參考下2013-06-06
Idea連接MySQL數(shù)據(jù)庫出現(xiàn)中文亂碼的問題
這篇文章主要介紹了Idea連接MySQL數(shù)據(jù)庫出現(xiàn)中文亂碼的問題,本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2021-04-04
MySQL中ROUND函數(shù)進行四舍五入操作陷阱分析
這篇文章主要介紹了MySQL中ROUND函數(shù)進行四舍五入操作陷阱,結合實例形式分析了mysql使用ROUND函數(shù)進行四舍五入運算中出現(xiàn)的問題及其錯誤原因,需要的朋友可以參考下2018-06-06