MySQL单表数据不要超过500万行:是经验数值,还是黄金铁律?

数据库 MySQL
今天,探讨一个有趣的话题:MySQL 单表数据达到多少时才需要考虑分库分表?有人说 2000 万行,也有人说 500 万行。那么,你觉得这个数值多少才合适呢?

 [[276385]]

今天,探讨一个有趣的话题:MySQL 单表数据达到多少时才需要考虑分库分表?有人说 2000 万行,也有人说 500 万行。那么,你觉得这个数值多少才合适呢?

[[276386]] 

曾经在中国互联网技术圈广为流传着这么一个说法:MySQL 单表数据量大于 2000 万行,性能会明显下降。事实上,这个传闻据说最早起源于百度。具体情况大概是这样的,当年的 DBA 测试 MySQL性能时发现,当单表的量在 2000 万行量级的时候,SQL 操作的性能急剧下降,因此,结论由此而来。然后又据说百度的工程师流动到业界的其它公司,也带去了这个信息,所以,就在业界流传开这么一个说法。

再后来,阿里巴巴《Java 开发手册》提出单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。对此,有阿里的黄金铁律支撑,所以,很多人设计大数据存储时,多会以此为标准,进行分表操作。

那么,你觉得这个数值多少才合适呢?为什么不是 300 万行,或者是 800 万行,而是 500 万行?也许你会说这个可能就是阿里的最佳实战的数值吧?那么,问题又来了,这个数值是如何评估出来的呢?稍等片刻,请你小小思考一会儿。

[[276387]] 

事实上,这个数值和实际记录的条数无关,而与 MySQL 的配置以及机器的硬件有关。因为,MySQL 为了提高性能,会将表的索引装载到内存中。InnoDB buffer size 足够的情况下,其能完成全加载进内存,查询不会有问题。但是,当单表数据库到达某个量级的上限时,导致内存无法存储其索引,使得之后的 SQL 查询会产生磁盘 IO,从而导致性能下降。当然,这个还有具体的表结构的设计有关,最终导致的问题都是内存限制。这里,增加硬件配置,可能会带来立竿见影的性能提升哈。

那么,我对于分库分表的观点是,需要结合实际需求,不宜过度设计,在项目一开始不采用分库与分表设计,而是随着业务的增长,在无法继续优化的情况下,再考虑分库与分表提高系统的性能。对此,阿里巴巴《Java 开发手册》补充到:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。那么,回到一开始的问题,你觉得这个数值多少才合适呢?我的建议是,根据自身的机器的情况综合评估,如果心里没有标准,那么暂时以 500 万行作为一个统一的标准,相对而言算是一个比较折中的数值。

 

责任编辑:武晓燕 来源: 服务端思维
相关推荐

2019-06-23 15:04:42

MySQL单表数据数值

2019-06-27 16:40:30

MySQL单表数据数据库

2018-12-05 09:20:02

MySQL数据库索引

2022-10-31 08:29:37

MySQL单表参数

2009-08-20 16:34:50

Linux源代码红帽Linux内核

2023-11-01 21:45:59

数据库MySQL单表

2021-03-02 13:56:24

Linux 5.12代码驱动

2011-05-03 09:10:12

项目管理程序员

2019-04-19 13:01:12

Java代码库Go代码移植

2024-03-04 00:01:00

锁表锁行MySQL

2019-01-03 09:29:15

Linux 系统 数据

2023-06-28 14:18:06

2010-09-27 11:55:47

SQL索引

2009-07-21 08:44:14

微软Linux内核开源操作系统

2009-07-21 08:51:33

微软发布Linux设备微软开源虚拟化

2020-08-17 17:10:54

机器学习聚类开发

2020-05-27 14:10:50

代码开发工具

2015-09-01 16:26:18

Linux内核

2009-01-04 15:38:07

索引SQL Server数据库

2020-03-10 16:28:31

代码开发工具
点赞
收藏

51CTO技术栈公众号