MySQL数据库是软件开发和中小型网站建立运用最为普遍的数据库之一，但是，很多人并不分明MySQL到底能支持多大的数据量，再加上某些国内CMS厂商把数据承载量的义务推给它，招致不理解MySQL的诸多站长对它产生了很多误解，那么，MySQL数据库的数据量到底能支持几呢？其实MySQL单表的上限，主要与操作系统支持的最大文件大小有关，我们看看官方的相关引见。
MySQL.jpg
MySQL 3.22 限制的表大小为4GB。由于在MySQL 3.23 中运用了MyISAM 存储引擎，最大表尺寸增加到了65536TB（2567 - 1字节）。由于允许的表尺寸更大，MySQL数据库的最大有效表尺寸通常是由操作系统对文件大小的限制决议的，而不是由MySQL内部限制决议的。
InnoDB 存储引擎将InnoDB 表保管在一个表空间内，该表空间可由数个文件创立。这样，表的大小就能超越单独文件的最大容量。表空间可包括原始磁盘分区，从而使得很大的表成为可能。表空间的最大容量为64TB。
实践上MySQL能接受的数据量的几主要和数据表的构造有关，并不是一个固定的数值。若表构造简单，就能接受比表构造复杂的数据量大些。
据D.V.B 团队以及Cmshelp 团队做CMS系统评测时的结果来看，MySQL单表大约在2千万条记载（4G）下可以良好运转，经过数据库的优化后5千万条记载（10G）下运转良好。那么为什么国内的某些CMS厂商还会把其产品本身负载差的义务推给MySQL呢？
这关于MySQL是不公平的，那些CMS厂商非但没有把内核做好反而还在添加很多花哨的功用，最终招致其产品本身负载过低。他们并没有针对本身负载效果作出相应的数据库优化计划及规范，而是继续保存着复杂的构造形成对MySQL的资源无休止的糜费，最终招致了其负载上的缺陷，于是他们便充沛发挥中国人的传统优势——变通：拈轻怕重的采用了所谓的分表式存储，固然在一定水平上缓解了本身负载的缺陷，但是招致了网站后期维护以及资源上的糜费，这样做能否是持久之计呢？固然他们处理了眼前的问题，但以后呢？难道想无休止的分表来到达目的？
用一个简单直白的比喻来形容，MySQL中的的表就像一块地皮，单表就相当于应用这块地盖高层建筑，充沛应用到达高人员负载，但分表就相当于用这块地盖了一间平房，假如为了到达高人员负载的话，就不时开设新地皮到达目的，但是我们要考虑，是地不够，还是技术程度不够，如此做法让人感到资源的糜费以及规划的严重缺陷。
那么关于这样的CMS系统，有谁敢用？难道为了到达让其良好的运转而无休止的更新效劳器配置么？况且大多数状况下一台效劳器中不是只要这么一个网站，那么我们就要考虑，我们能否是为了满足这么庞大的小CMS而掏腰包。
倡议某些CMS厂商改善本人的产品，让用户取得更好的利益。否则，还有谁会用你们的软件产品呢？