CMS不要讓MySQL為你流淚
更新時間：2008年12月12日 11:57:11 作者：
MySQL是中小型網(wǎng)站普遍使用的數(shù)據(jù)庫之一，然而，很多人并不清楚MySQL到底能支持多大的數(shù)據(jù)量，再加上某些國內(nèi)CMS廠商把數(shù)據(jù)承載量的責(zé)任推給它，導(dǎo)致很多不了解MySQL的站長對它產(chǎn)生了很多誤解
那么，MySQL的數(shù)據(jù)量到底能支持多少呢？其實MySQL單表的上限，主要與操作系統(tǒng)支持的最大文件大小有關(guān)。我們來看一下官方的介紹。
1.4.4. MySQL表最大能達(dá)到多少
MySQL 3.22限制的表大小為4GB。由于在MySQL 3.23中使用了MyISAM存儲引擎，最大表尺寸增加到了65536TB（2567 – 1字節(jié)）。由于允許的表尺寸更大，MySQL數(shù)據(jù)庫的最大有效表尺寸通常是由操作系統(tǒng)對文件大小的限制決定的，而不是由MySQL內(nèi)部限制決定的。
InnoDB存儲引擎將InnoDB表保存在一個表空間內(nèi)，該表空間可由數(shù)個文件創(chuàng)建。這樣，表的大小就能超過單獨文件的最大容量。表空間可包括原始磁盤分區(qū)，從而使得很大的表成為可能。表空間的最大容量為64TB。
在下面的表格中，列出了一些關(guān)于操作系統(tǒng)文件大小限制的示例。這僅是初步指南，并不是最終的。要想了解最新信息，請參閱關(guān)于操作系統(tǒng)的文檔。
MySQL表最大能達(dá)到多少：http://dev.mysql.com/doc/refman/5.1/zh/introduction.html#table-size
事實上MySQL能承受的數(shù)據(jù)量的多少主要和數(shù)據(jù)表的結(jié)構(gòu)有關(guān)，并不是一個固定的數(shù)值。表的結(jié)構(gòu)簡單，則能承受的數(shù)據(jù)量相對比結(jié)構(gòu)復(fù)雜時大些。
據(jù)D.V.B團(tuán)隊以及Cmshelp團(tuán)隊做CMS系統(tǒng)評測時的結(jié)果看來，MySQL單表一般在2千萬條記錄（4G）下能夠良好運行，經(jīng)過數(shù)據(jù)庫的優(yōu)化后5千萬條記錄（10G）下運行良好。那么為什么國內(nèi)的某些CMS廠商還會把其產(chǎn)品自身負(fù)載差的責(zé)任推給MySQL呢？
這對于MySQL是不公平的，那些CMS廠商非但沒有把內(nèi)核做好反而還在添加很多花哨的功能，最終導(dǎo)致其產(chǎn)品自身負(fù)載過低。他們并沒有針對自身負(fù)載效果作出相應(yīng)的數(shù)據(jù)庫優(yōu)化方案及標(biāo)準(zhǔn)，而是繼續(xù)保留著復(fù)雜的結(jié)構(gòu)造成對MySQL的資源無休止的浪費，最終導(dǎo)致了其負(fù)載上的缺陷，于是他們便充分發(fā)揮中國人的傳統(tǒng)優(yōu)勢——變通：避重就輕的采用了所謂的分表式存儲，雖然在一定程度上緩解了自身負(fù)載的缺陷，但是導(dǎo)致了網(wǎng)站后期維護(hù)以及資源上的浪費，這樣做是否是長久之計呢？雖然他們解決了眼前的問題，但以后呢？難道想無休止的分表來達(dá)到目的？MYLB.NET.CN博主追峰用一個不恰當(dāng)?shù)谋扔鱽硇稳荩琈ySQL中的的表就像一塊地，單表就相當(dāng)于利用這塊地蓋高層建筑充分利用達(dá)到高人員負(fù)載，但分表就相當(dāng)于用這塊地蓋了一間平房，如果為了達(dá)到高人員負(fù)載的話那就需要另開地皮達(dá)到目的，但是我們要思考，是地不夠，還是他的能力不夠，如此做法讓人感到資源的浪費以及規(guī)劃的嚴(yán)重缺陷。那么對于這樣的CMS系統(tǒng)，有誰敢用？難道為了達(dá)到讓其良好的運行而無休止的更換著服務(wù)器配置么？況且大多情況下一臺服務(wù)器中不是只有這么一個網(wǎng)站，那么我們就要思考，我們的腰包是否是為了滿足這么龐大的小CMS而生。
對于某些CMS廠商，MYLB.NET.CN博主追峰只能說其把負(fù)載問題推到MySQL身上的做法是極其不負(fù)責(zé)任的行為，分表的做法是避重就輕毫無責(zé)任感的做法，這不僅是對自己的不負(fù)責(zé)，更是對其用戶的不負(fù)責(zé)行為，難道你想用把責(zé)任推給MySQL以及分表的做法來掩飾自己產(chǎn)品的不足么？大錯特錯，你的這種做法只能愚弄那些剛接觸網(wǎng)站系統(tǒng)對于源碼以及數(shù)據(jù)庫不大了解的初級站長，但是對于大多圈內(nèi)人士你是無法欺騙的；建議這類廠商還是把到各群和網(wǎng)站挑撥是非、夸大宣傳、詆毀他人的時間多多利用到如何改善自己產(chǎn)品讓用戶更好的獲益上；因為不管多初級的站長也會有成為老站長對源碼和數(shù)據(jù)庫駕輕就熟的時候，到那時看清你們本質(zhì)的人會更多。
如此毫無責(zé)任感可言的CMS廠商會有多少用戶會忠實于你呢？對自己的產(chǎn)品都沒有責(zé)任感，那么對待用戶還剩下多少呢？還有誰敢去選擇你們的產(chǎn)品呢？
這樣不思進(jìn)取，說一套做一套了，吹噓自己的行為只能是把自己生生地捧得很高，但是別忘了，你的高度是自己吹上去的，用戶才是真正的評論者，到時候你們會摔到什么程度那就要自己思考了。感謝大家對MYLB.NET.CN的支持。
1.4.4. MySQL表最大能達(dá)到多少
MySQL 3.22限制的表大小為4GB。由于在MySQL 3.23中使用了MyISAM存儲引擎，最大表尺寸增加到了65536TB（2567 – 1字節(jié)）。由于允許的表尺寸更大，MySQL數(shù)據(jù)庫的最大有效表尺寸通常是由操作系統(tǒng)對文件大小的限制決定的，而不是由MySQL內(nèi)部限制決定的。
InnoDB存儲引擎將InnoDB表保存在一個表空間內(nèi)，該表空間可由數(shù)個文件創(chuàng)建。這樣，表的大小就能超過單獨文件的最大容量。表空間可包括原始磁盤分區(qū)，從而使得很大的表成為可能。表空間的最大容量為64TB。
在下面的表格中，列出了一些關(guān)于操作系統(tǒng)文件大小限制的示例。這僅是初步指南，并不是最終的。要想了解最新信息，請參閱關(guān)于操作系統(tǒng)的文檔。
MySQL表最大能達(dá)到多少：http://dev.mysql.com/doc/refman/5.1/zh/introduction.html#table-size
事實上MySQL能承受的數(shù)據(jù)量的多少主要和數(shù)據(jù)表的結(jié)構(gòu)有關(guān)，并不是一個固定的數(shù)值。表的結(jié)構(gòu)簡單，則能承受的數(shù)據(jù)量相對比結(jié)構(gòu)復(fù)雜時大些。
據(jù)D.V.B團(tuán)隊以及Cmshelp團(tuán)隊做CMS系統(tǒng)評測時的結(jié)果看來，MySQL單表一般在2千萬條記錄（4G）下能夠良好運行，經(jīng)過數(shù)據(jù)庫的優(yōu)化后5千萬條記錄（10G）下運行良好。那么為什么國內(nèi)的某些CMS廠商還會把其產(chǎn)品自身負(fù)載差的責(zé)任推給MySQL呢？
這對于MySQL是不公平的，那些CMS廠商非但沒有把內(nèi)核做好反而還在添加很多花哨的功能，最終導(dǎo)致其產(chǎn)品自身負(fù)載過低。他們并沒有針對自身負(fù)載效果作出相應(yīng)的數(shù)據(jù)庫優(yōu)化方案及標(biāo)準(zhǔn)，而是繼續(xù)保留著復(fù)雜的結(jié)構(gòu)造成對MySQL的資源無休止的浪費，最終導(dǎo)致了其負(fù)載上的缺陷，于是他們便充分發(fā)揮中國人的傳統(tǒng)優(yōu)勢——變通：避重就輕的采用了所謂的分表式存儲，雖然在一定程度上緩解了自身負(fù)載的缺陷，但是導(dǎo)致了網(wǎng)站后期維護(hù)以及資源上的浪費，這樣做是否是長久之計呢？雖然他們解決了眼前的問題，但以后呢？難道想無休止的分表來達(dá)到目的？MYLB.NET.CN博主追峰用一個不恰當(dāng)?shù)谋扔鱽硇稳荩琈ySQL中的的表就像一塊地，單表就相當(dāng)于利用這塊地蓋高層建筑充分利用達(dá)到高人員負(fù)載，但分表就相當(dāng)于用這塊地蓋了一間平房，如果為了達(dá)到高人員負(fù)載的話那就需要另開地皮達(dá)到目的，但是我們要思考，是地不夠，還是他的能力不夠，如此做法讓人感到資源的浪費以及規(guī)劃的嚴(yán)重缺陷。那么對于這樣的CMS系統(tǒng)，有誰敢用？難道為了達(dá)到讓其良好的運行而無休止的更換著服務(wù)器配置么？況且大多情況下一臺服務(wù)器中不是只有這么一個網(wǎng)站，那么我們就要思考，我們的腰包是否是為了滿足這么龐大的小CMS而生。
對于某些CMS廠商，MYLB.NET.CN博主追峰只能說其把負(fù)載問題推到MySQL身上的做法是極其不負(fù)責(zé)任的行為，分表的做法是避重就輕毫無責(zé)任感的做法，這不僅是對自己的不負(fù)責(zé)，更是對其用戶的不負(fù)責(zé)行為，難道你想用把責(zé)任推給MySQL以及分表的做法來掩飾自己產(chǎn)品的不足么？大錯特錯，你的這種做法只能愚弄那些剛接觸網(wǎng)站系統(tǒng)對于源碼以及數(shù)據(jù)庫不大了解的初級站長，但是對于大多圈內(nèi)人士你是無法欺騙的；建議這類廠商還是把到各群和網(wǎng)站挑撥是非、夸大宣傳、詆毀他人的時間多多利用到如何改善自己產(chǎn)品讓用戶更好的獲益上；因為不管多初級的站長也會有成為老站長對源碼和數(shù)據(jù)庫駕輕就熟的時候，到那時看清你們本質(zhì)的人會更多。
如此毫無責(zé)任感可言的CMS廠商會有多少用戶會忠實于你呢？對自己的產(chǎn)品都沒有責(zé)任感，那么對待用戶還剩下多少呢？還有誰敢去選擇你們的產(chǎn)品呢？
這樣不思進(jìn)取，說一套做一套了，吹噓自己的行為只能是把自己生生地捧得很高，但是別忘了，你的高度是自己吹上去的，用戶才是真正的評論者，到時候你們會摔到什么程度那就要自己思考了。感謝大家對MYLB.NET.CN的支持。
相關(guān)文章
pt-query-digest是用于分析mysql慢查詢的一個工具，它可以分析binlog、General?log、slowlog，也可以通過SHOWPROCESSLIST或者通過tcpdump抓取的MySQL協(xié)議數(shù)據(jù)來進(jìn)行分析，這篇文章主要介紹了MySQL慢查詢分析工具pt-query-digest詳解,需要的朋友可以參考下2023-01-01
這篇文章主要介紹了MySQL - MVCC的相關(guān)資料，幫助大家更好的理解和使用MySQL數(shù)據(jù)庫，感興趣的朋友可以了解下2020-11-11
隨著時間的推移，表里面的數(shù)據(jù)越來越多，表數(shù)據(jù)文件越來越大，數(shù)據(jù)庫占用的空間自然也逐漸增長，本文主要介紹了MySQL表空間回收，感興趣的可以了解一下2021-09-09
mysql之跨庫關(guān)聯(lián)查詢(dblink)問題
這篇文章主要介紹了mysql之跨庫關(guān)聯(lián)查詢(dblink)問題，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2023-03-03
MySQL是目前來說最好的 RDBMS應(yīng)用軟件之一，這篇文章主要給大家介紹了關(guān)于MySql基本操作的相關(guān)資料，非常適合mysql新手入門，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-05-05
這篇文章主要介紹了Mysql 查詢時間段交集的方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2021-06-06
本文將詳細(xì)介紹mysql 初始執(zhí)行文件的使用方法，現(xiàn)在曬出來和大家分享下，希望可以幫助你們2012-11-11
Eclipse與MySQL數(shù)據(jù)庫的連接教程(已實操)
用eclipse編寫的好的代碼,我們怎么才能連接到數(shù)據(jù)庫呢?下面這篇文章主要給大家介紹了關(guān)于Eclipse與MySQL數(shù)據(jù)庫連接的相關(guān)資料,下面的操作是經(jīng)本人驗證,確實可行,需要的朋友可以參考下2023-05-05
我想很多朋友都不怎么會在mysql中使用float類型，特別是用到金錢時我們可能會用雙精度來做，我們知道m(xù)ysql的float類型是單精度浮點類型不小心就會導(dǎo)致數(shù)據(jù)誤差2012-11-11
MySQL易學(xué)易用，且附帶豐富的技術(shù)文檔，這二個因素使之被廣泛應(yīng)用。然而，隨著MySQL發(fā)展之迅速，即使一個MySQL老手有時也會為該軟件出其不意的功能感嘆。2011-01-01