mysql的最大数据存储量没有最大限制。
最多也就是单字段的长度有限制,那跟字段的数据类型有关,而对于数据表的大小一般不要超过2G,超过了效率会比较慢,建议分开多表存。
上MySQL 能承受的数据量的多少主要和数据表的结构有关,并不是一个固定的数值。表的结构简单,则能承受的数据量相对比结构复杂时大些。
据D.V.B 团队以及Cmshelp 团队做CMS 系统评测时的结果来看,MySQL单表大约在2千万条记录(4G)下能够良好运行,经过数据库的优化后5千万条记录(10G)下运行良好。
扩展资料
由于MySQL是开放源代码的,因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。
MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下,MySQL是管理内容最好的选择。
参考资料来源:百度百科-MySQL数据库
我们经常会遇到 *** 作一张大表,发现 *** 作时间过长或影响在线业务了,想要回退大表 *** 作的场景。在我们停止大表 *** 作之后,等待回滚是一个很漫长的过程,尽管你可能对知道一些缩短时间的方法,处于对生产环境数据完整性的敬畏,也会选择不做介入。最终选择不作为的原因大多源于对 *** 作影响的不确定性。实践出真知,下面针对两种主要提升事务回滚速度的方式进行验证,一种是提升 *** 作可用内存空间,一种是通过停实例,禁用 redo 回滚方式进行进行验证。仔细阅读过官方手册的同学,一定留意到了对于提升大事务回滚效率,官方提供了两种方法:一是增加 innodb_buffer_pool_size 参数大小,二是合理利用 innodb_force_recovery=3 参数,跳过事务回滚过程。第一种方式比较温和,innodb_buffer_pool_size 参数是可以动态调整的,可行性也较高。第二种方式相较之下较暴力,但效果较好。
两种方式各有自己的优点,第一种方式对线上业务系统影响较小,不会中断在线业务。第二种方式效果更显著,会短暂影响业务连续,回滚所有没有提交的事务。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)