MySQL數(shù)據(jù)庫是用于軟件開發(fā)和中小型網(wǎng)站建設的最常用數(shù)據(jù)庫之一。

但是，許多人不知道MySQL可以支持多少數(shù)據(jù)，并且一些國內(nèi)CMS制造商擁有大量數(shù)據(jù)。 它承擔了責任，許多不了解MySQL的網(wǎng)站管理員對此有很多誤解。 那么，MySQL數(shù)據(jù)庫可以支持多少數(shù)據(jù)？ 實際上，MySQL單表的上限主要與操作系統(tǒng)支持的最大文件大小有關(guān)。 讓我們看一下官方介紹。   MySQL 3.22 將表大小限制為4GB。

由于MySQL 3.23中使用了MyISAM存儲引擎，因此最大表大小已增加到65536TB（2567- 1字節(jié)）。 由于允許的表大小較大，因此，MySQL數(shù)據(jù)庫的最大有效表大小通常由操作系統(tǒng)的文件大小限制而不是由MySQL內(nèi)部限制確定。 

InnoDB存儲引擎將InnoDB表保存在一個表空間中，該表空間可以由多個文件創(chuàng)建。 這樣，表的大小可以超過單個文件的最大容量。 表空間可以包含原始磁盤分區(qū)，從而使非常大的表成為可能。 表空間的最大容量為64TB。   實際上，MySQL可以承受的數(shù)據(jù)量主要與數(shù)據(jù)表的結(jié)構(gòu)有關(guān)，而不是固定值。 如果表結(jié)構(gòu)簡單，則它可以承載比表結(jié)構(gòu)更大的數(shù)據(jù)量。

  根據(jù)DVB團隊和Cmshelp團隊進行的CMS系統(tǒng)評估的結(jié)果，MySQL單個表可以很好地運行，具有大約2000萬條記錄（4G）和經(jīng)過數(shù)據(jù)庫優(yōu)化后的5000萬條記錄（10G）。 它運作良好。

那么，為什么一些國內(nèi)的CMS制造商仍然將負擔不佳的產(chǎn)品責任推給MySQL？   這對MySQL不公平。 那些CMS供應商沒有很好地完成內(nèi)核工作，而是仍然添加了許多新穎的功能，最終導致其產(chǎn)品的低負載。 他們沒有針對自己的負載效果制定相應的數(shù)據(jù)庫優(yōu)化方案和標準，而是繼續(xù)保留了復雜的結(jié)構(gòu)，這導致了MySQL資源的無盡浪費，最終導致了其負載方面的缺陷，因此他們充分發(fā)揮了中文的傳統(tǒng)優(yōu)勢。

  .com的優(yōu)勢是靈活的：采用所謂的拆分表存儲來避免重量和重量。 盡管可以在一定程度上緩解自身負擔的缺陷，但會導致網(wǎng)站維護和資源浪費。 這是一個長期的解決方案嗎？  ？ 盡管他們解決了眼前的問題，但將來會發(fā)生什么？ 您想不斷實現(xiàn)目標嗎？ 

用簡單明了的類比來描述，MySQL中的表就像一塊土地。 一張桌子等同于使用這塊土地來建造高層建筑物并充分利用高的人員負擔，而子桌子等同于使用在這塊土地上建造的簡易別墅。 如果要達到高的人員負擔，將繼續(xù)開辟新的土地以實現(xiàn)目標，但是我們必須考慮土地是否不足或技術(shù)水平是否不足。 這種方法使人們感到浪費資源并計劃嚴重的缺陷。 

那么誰敢使用這樣的CMS系統(tǒng)？ 是否要不停地更新服務器配置以實現(xiàn)良好的運行？ 而且，在大多數(shù)情況下，下一個服務器中不僅有這樣的網(wǎng)站，因此我們必須考慮是否要為如此龐大的小型CMS付款。   建議某些CMS制造商改進其產(chǎn)品，以便用戶獲得更好的收益。 否則，還有誰會使用您的軟件產(chǎn)品？