如何应对MySQL单表数据量过大：垂直分表与水平分表策略解析

最新推荐文章于 2024-08-16 07:58:08 发布

一日三餐384

最新推荐文章于 2024-08-16 07:58:08 发布

阅读量599

点赞数 5

文章标签：数据库

本文链接：https://blog.csdn.net/weixin_62647396/article/details/137789626

版权

文章讨论了在大型项目中处理大量用户数据时，如何通过垂直分表（拆列）和水平分表（按ID取模或范围分）来提高MySQL性能。两种方法的优缺点以及可能遇到的扩展性和读写热点问题被详细分析。同时推荐了小白debug的相关资源以获取更多解决方案。

摘要由CSDN通过智能技术生成

话接上回，单表最大数据建议两千万，那如果开发一个项目，预计注册量达到一个亿怎么办。

单表内放这么多数据，MYSQL底层B+树的层级结构就可能会变得很高，磁盘io次数变多，性能会大幅度降低。所以考虑数据库分表。

这里的分表分为垂直分表和水平分表两种。

垂直分表：

原理比较简单，一般就是把某几列拆成一个新表，这样原来的表就小了，拆几列出去，那数据表里的每行数据就会变少，单个16K数据页就能放入越多的行数，这样发生查询时需要的数据页就会越少，那磁盘IO也会越少，所以性能就会越快。

水平分表：

水平分表有好几种做法，但不管是哪种，本质上都是将原来的user表变成USER0到user_n这样的N张小，每一张小表里只保存了一部分数据，一般是500万到2000万。

第一种：根据ID取模分表

假设我们一共分了两张表，分别是user_0和user_1，此时模等于2，我们将输入的ID与模进行求余数操，如ID=2,4,6的时候，会被写到user_0这张表。ID=1,3,5和2取模得到1，于是就能知道应该写到user_1这张表里。

优点：

比较简单

读写数据都可以很均匀的分摊到每个分表上

缺点：如果想要扩展表的个数，比如从两张表变成3张表，那同样还是ID=3的数据，以前3和2取模得到1，所以ID=3的数据会放在USER1表里，现在3和3取模得到0，那就要放在USER0这张表里，跟原来的USER1就对不上了，这就需要考虑数据迁移。

第二种：根据ID范围分表

假设我们每张分表都能存放500万条数据，那user_0就存放ID为1~500万的数，user_1就存放ID在500万到1000万之间的数据。假设现在有条数据，ID=3000万要读写条数据，就需要将3000万除以500万得到6，那就可以知道这条数据属于user_6一表，于是就去读写user_6表就行了。

优点：根据ID范围去分表就能很好的解决ID取模时数据表的扩展问题。

缺点：假设新注册玩家的ID是不断加一的，那么在某段时间内，ID会集中在某个分片范围内，比如在4000万到6000万的范围，数据会不断写入这个特定的分表中，并没有起到分摊数据读写压力的效果，这就是所谓的读写热点问题。解决读写热点问题最简单的方案就是让ID变得随机，这样ID就能随机分散到所有表上，分摊读写压力。