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