CMS不要让MySQL为你流泪

这篇文章主要为大家详细介绍了CMS不要让MySQL为你流泪，具有一定的参考价值，可以用来参考一下。

感兴趣的小伙伴，下面一起跟随四海网的小编小韵来看看吧！

那么，MySQL的数据量到底能支持多少呢？其实MySQL单表的上限，主要与操作系统支持的最大文件大小有关。我们来看一下官方的介绍。
1.4.4. MySQL表最大能达到多少
MySQL 3.22限制的表大小为4GB。由于在MySQL 3.23中使用了MyISAM存储引擎，最大表尺寸增加到了65536TB（2567 – 1字节）。由于允许的表尺寸更大，MySQL数据库的最大有效表尺寸通常是由操作系统对文件大小的限制决定的，而不是由MySQL内部限制决定的。
InnoDB存储引擎将InnoDB表保存在一个表空间内，该表空间可由数个文件创建。这样，表的大小就能超过单独文件的最大容量。表空间可包括原始磁盘分区，从而使得很大的表成为可能。表空间的最大容量为64TB。
在下面的表格中，列出了一些关于操作系统文件大小限制的示例。这仅是初步指南，并不是最终的。要想了解最新信息，请参阅关于操作系统的文档。
MySQL表最大能达到多少：http://dev.mysql.com/doc/refman/5.1/zh/introduction.html#table-size
事实上MySQL能承受的数据量的多少主要和数据表的结构有关，并不是一个固定的数值。表的结构简单，则能承受的数据量相对比结构复杂时大些。
据D.V.B团队以及Cmshelp团队做CMS系统评测时的结果看来，MySQL单表一般在2千万条记录（4G）下能够良好运行，经过数据库的优化后5千万条记录（10G）下运行良好。那么为什么国内的某些CMS厂商还会把其产品自身负载差的责任推给MySQL呢？
这对于MySQL是不公平的，那些CMS厂商非但没有把内核做好反而还在添加很多花哨的功能，最终导致其产品自身负载过低。他们并没有针对自身负载效果作出相应的数据库优化方案及标准，而是继续保留着复杂的结构造成对MySQL的资源无休止的浪费，最终导致了其负载上的缺陷，于是他们便充分发挥中国人的传统优势——变通：避重就轻的采用了所谓的分表式存储，虽然在一定程度上缓解了自身负载的缺陷，但是导致了网站后期维护以及资源上的浪费，这样做是否是长久之计呢？虽然他们解决了眼前的问题，但以后呢？难道想无休止的分表来达到目的？MYLB.NET.CN博主追峰用一个不恰当的比喻来形容，MySQL中的的表就像一块地，单表就相当于利用这块地盖高层建筑充分利用达到高人员负载，但分表就相当于用这块地盖了一间平房，如果为了达到高人员负载的话那就需要另开地皮达到目的，但是我们要思考，是地不够，还是他的能力不够，如此做法让人感到资源的浪费以及规划的严重缺陷。那么对于这样的CMS系统，有谁敢用？难道为了达到让其良好的运行而无休止的更换着服务器配置么？况且大多情况下一台服务器中不是只有这么一个网站，那么我们就要思考，我们的腰包是否是为了满足这么庞大的小CMS而生。
对于某些CMS厂商，MYLB.NET.CN博主追峰只能说其把负载问题推到MySQL身上的做法是极其不负责任的行为，分表的做法是避重就轻毫无责任感的做法，这不仅是对自己的不负责，更是对其用户的不负责行为，难道你想用把责任推给MySQL以及分表的做法来掩饰自己产品的不足么？大错特错，你的这种做法只能愚弄那些刚接触网站系统对于源码以及数据库不大了解的初级站长，但是对于大多圈内人士你是无法欺骗的；建议这类厂商还是把到各群和网站挑拨是非、夸大宣传、诋毁他人的时间多多利用到如何改善自己产品让用户更好的获益上；因为不管多初级的站长也会有成为老站长对源码和数据库驾轻就熟的时候，到那时看清你们本质的人会更多。
如此毫无责任感可言的CMS厂商会有多少用户会忠实于你呢？对自己的产品都没有责任感，那么对待用户还剩下多少呢？还有谁敢去选择你们的产品呢？
这样不思进取，说一套做一套了，吹嘘自己的行为只能是把自己生生地捧得很高，但是别忘了，你的高度是自己吹上去的，用户才是真正的评论者，到时候你们会摔到什么程度那就要自己思考了。感谢大家对MYLB.NET.CN的支持。

本文来自：http://www.q1010.com/177/10777-0.html

注：关于CMS不要让MySQL为你流泪的内容就先介绍到这里，更多相关文章的可以留意四海网的其他信息。

关键词：MYSQL