mysql的最大数据存储量是多少

mysql的最大数据存储量没有最大限制。

最多也就是单字段的长度有限制，那跟字段的数据类型有关，而对于数据表的大小一般不要超过2G，超过了效率会比较慢，建议分开多表存。

上MySQL 能承受的数据量的多少主要和数据表的结构有关，并不是一个固定的数值。表的结构简单，则能承受的数据量相对比结构复杂时大些。

据D.V.B 团队以及Cmshelp 团队做CMS 系统评测时的结果来看，MySQL单表大约在2千万条记录（4G）下能够良好运行，经过数据库的优化后5千万条记录（10G）下运行良好。

扩展资料

由于MySQL是开放源代码的，因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。

MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下，MySQL是管理内容最好的选择。

参考资料来源：百度百科-MySQL数据库

用 pt-table-checksum 时，会不会影响业务性能？

实验

实验开始前，给大家分享一个小经验：任何性能评估，不要相信别人的评测结果，要在自己的环境上测试，并（大概）知晓原理。

我们先建一对主从：

然后用 mysqlslap跑一个持续的压力：

开另外一个会话，将 master 上的 general log 打开：

然后通过 pt-table-checksum 进行一次比较：

查看 master 的 general log，由于 mysqlslap 的影响，general log 中有很多内容，我们找到与 pt-table-checksum 相关的线程：

将该线程的 *** 作单独列出来：

*** 作比较多，我们一点一点来说明：

这里工具调小了 innodb 锁等待时间。使得之后的 *** 作，只要在 innodb 上稍微有锁等待，就会马上放弃 *** 作，对业务影响很小。

另外工具调小了 wait_timeout 时间，倒是没有特别的作用。

工具将隔离级别调整为了 RR 级别，事务的维护代价会比 RC 要高，不过后面我们会看到工具使用的每个事务都很小，加上之前提到 innodb 锁等待时间调到很小，对线上业务产生的成本比较小。

RR 级别是数据对比的基本要求。

工具通过一系列 *** 作，了解表的概况。工具是一个数据块一个数据块进行校验，这里获取了第一个数据块的下边界。

接下来工具获取了下一个数据块的下边界，每个 SQL前都会 EXPLAIN 一下，看一下执行成本，非常小心翼翼。

之后工具获取了一个数据块的 checksum，这个数据块不大，如果跟业务流量有冲突，会马上出发 innodb 的锁超时，立刻退让。

以上是 pt-table-checksum 的一些设计，可以看到这几处都是精心维护了业务流量不受影响。

工具还设计了其他的一些机制保障业务流量，比如参数 --max-load 和 --pause-file 等，还有精心设计的数据块划分方法，索引选择方法等。大家根据自己的情况配合使用即可达到很好的效果。

总结

本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量，坊间会流传工具的各种参数建议或者不建议使用，算命的情况比较多，大家都可以用简单的实验来分析其中机制。

还是那个观点，性能测试不能相信道听途说，得通过实验去分析。

随着Web应用变得越来越复杂，单纯的MySQL + Memcached似乎已满足不了数据存储的需求，一些企业纷纷转向NoSQL方案，比如MongoDB、CouchDB、 TokyoCabinet/Tyrant、Cassandra等。在他们看来，如果数据访问模式不是很复杂，用不上SQL数据库。然而，DeNA公司截然相反，他们选择了 "only MySQL" 的方案，且获得了远远超越NoSQL的性能。

该公司仍在使用MySQL + Memcached，Memcached主要用于前端Cache，比如预处理的HTML、计数和摘要信息等，但数据行并不放在Cache里，而是直接从数据库查，因为普通的服务器就可以获得75万次每秒的查询，当前又有哪种NoSQL可以做到呢？

可以使用sysbench、super-smack、mysqlslap等工具测试MySQL性能，比如

[matsunobu@host ~]$ mysqlslap --query="select user_name,..

from test.user where user_id=1" \

--number-of-queries=10000000 --concurrency=30 --host=xxx -uroot

然后使用如下命令得到每秒读取的行数，

[matsunobu@host ~]$ mysqladmin extended-status -i 1 -r -uroot \

| grep -e "Com_select"

...

| Com_select | 107069 |

| Com_select | 108873 |

| Com_select | 108921 |

| Com_select | 109511 |

| Com_select | 108084 |

| Com_select | 108483 |

| Com_select | 108115 |

...

可以使用vmstat和Oprofile等工具诊断系统瓶颈。

MySQL Cluster因为性能问题一直受人批判，为改善这种情况引入了NDBAPI，使得性能提升了N倍。但对于非集群情况怎么优化呢？通过MySQL瓶颈分 析，发现大部分时间花费在SQL解析和表 *** 作上，如果绕过这层 *** 作直接存取存储引擎，可大大提升性能，MySQL的插件HandlerSocket正是由 此获得了每秒75万次查询 *** 作的性能，这个评测数据无疑会颠覆整个NoSQL世界。另外，HandlerSocket支持批量读取和写 *** 作，这进一步提升 了它的性能。

---