开发者社区> stefanie燕> 正文

小微企业阿里云最佳实践系列(六):千万、上亿条数据在阿里云 MySQL 云数据库下的性能表现

简介: 阅读对象 本博文主要写给创业团队、技术团队人数 < 5 人、没有专业运维等小微企业作为参考,需要掌握基础的服务器管理、软件开发等经验。 博文主要内容 本博文主要为大家介绍阿里云的 MySQL 云数据库性能对别,通过 1000 万条数据以及 1 亿条数据在 RDS for MySQL 上面的表现来粗略的了解数据性能,高配版选择的 8 核 16 G 内存的 MySQL 数据库,低配选择的 1 核 1 G 内存的数据库。
+关注继续查看

阅读对象

本博文主要写给创业团队、技术团队人数 < 5 人、没有专业运维等小微企业作为参考,需要掌握基础的服务器管理、软件开发等经验。

博文主要内容

本博文主要为大家介绍阿里云的 MySQL 云数据库性能对别,通过 1000 万条数据以及 1 亿条数据在 RDS for MySQL 上面的表现来粗略的了解数据性能,高配版选择的 8 核 16 G 内存的 MySQL 数据库,低配选择的 1 核 1 G 内存的数据库。

实践过程

第一步:在控制台购买两种配置的数据

这里我们为了测试,选择按量付费,可以看到两种配置的价格差距在 10~12 倍左右,一般我们个人博客、小型企业网站选择 1 核 1 G 的配置完全够用,这里我们为了测试 MySQL 的性能所以选择了一个 8 核 16 G 的高配,当然,阿里云也提供了更高配置的数据库,大家可以自行选择进行测试。
1.一核一G内存数据库购买信息.
image

2.八核十六G内存数据库购买信息.png
image

第二步:初始化数据库配置、账号、数据库等

在数据库购买成功之后,阿里云会为了我们初始化创建数据库,这里需要耐心等待(博主等待了 5 分钟左右,比自己搭建 MySQL 还是快不少)
3.耐心等待数据库创建完成.png
image

数据库初始化完成之后我们可是开始创建账号了,这里为了测试方便,我们选择使用 root 账号并设置一个高强度的密码(生产环境不建议使用高权限 root 账号,建议使用普通账号)
4.低配的数据库创建高权限账号.pngimage

在阿里云提供的 MySQL 在线管理工具首次使用时,我们需要设置管理工具的白名单,按照弹出的提示点击设置本实例即可
5.设置 DMS 数据管理的白名单.pngimage

登录到 MySQL 数据库实例之后,我们需要按照以下的步骤创建数据库,这里我们以 mysql_test 命名来创建一个测试数据库
6.创建测试数据库.pngiimage

第三步:创建测试表以及快速生成测试数据

完成数据库创建之后,我们需要点击左上角这里选择创建的数据(若下拉框未显示,点击旁边的刷新按钮即可),
这里我们添加一些常用的字段:ID、创建时间、修改时间、姓名、手机号、身份证号、用户名、余额
7.创建用于测试的表.pngimage

创建好表之后,我们接下来生成测试数据,阿里云的 DMS 数据管理工具提供了强大的“自动生成测试数据”功能,这里给我们带来了极大的方便。右键点击表名,在弹出的菜单中选择“自动生成测试数据”,然后我们为每个字段选择对应的生成方式(阿里云提供了强大的生成规则,可以在面板中灵活始终各种规则),生成行数这里最大可以选择到 100 万行,这里我们因为要测试上千万、上亿的数据,选择最大上限 100 万行。
8.快速生成测试数据.pngimage

生成好了数据之后我们可以浏览生成的数据,这里可以看到生成的测试数据几乎和真实数据没有什么区别。
9.查看生成的数据.pngimage

第四步:对 MySQL 进行简单的性能测试

在我们测试之前,我们需要对测试数据进行快速复制,我们可以采用以下的 SQL 进行翻倍复制到 1600 万行数据级别

insert into pre_user(name, mobile, id_no, username, balance) select name, mobile, id_no, username, balance from pre_user;

每执行一次,数据库中的数据都会增加一倍,从 100 万行数据增加到 1600 万行数据我们需要执行 4 次,这里可能执行的时间比较长,我们可以两个数据库(高配和低配)一起执行。数据快速复制完成之后我们查询一下数据行数,显示有 1600 万行数据。
10.执行简单的 SQL 查看性能.pngimage

我们为需要测试的字段增加索引(未增加索引的情况下,100 万行数据查询需要 400 毫秒,可见索引的重要性)
11.为需要测试的字段建立索引.pngimage

索引创建好之后我们再次查询数据,在 1600 万行数据的级别下,查询返回 16 行数据总共耗时 28 毫秒,基本上可以满足使用
12.索引创建成功之后我们再次执行查询语句.pngimage

我们分别在高配和低配的数据库上再次执行同样的查询,我们发现高配的只需要 3 毫秒,低配的也只需要 9 毫秒,这里可以看出同样的查询,第二次比第一次快两倍左右
13.两边性能比较.pngimage

查看一下数据库的存储空间,我们发现数据占用了 1.8 GB,索引也占用了 1.8 GB,说明增加索引会增加数据库使用空间,我们应当按照最小化原则以及结合性能要求方面综合考量哪些字段应该增加索引,哪些字段不应该增加索引,一味的增加索引也会造成数据库的负担。
14.查看存储空间.pngimage

第五步:在 3200 万条数据以及 6400 万条数据下的 MySQL 性能表现

刚才我们简单测试了一下 1600 万条数据,这里我们把数据增加到 3200 万条以及 6400 万条数据再进行这里。由于数据量过大,1 核 1 G 的数据库复制较慢,我们这里直接测试高配的数据库(同样使用之前的快速复制 SQL,执行过程等待时间较长,需要耐心等待)。

增加到 3200 万条数据时,数据占用了 3.18 GB,索引占用了 3.86 GB,数据
15.增加到 3200 万级别时的存储空间.pngimage

我们通过常规的 SQL 按照手机号查询,在 3200 万条数据中查找 32 行数据只用了 3 毫秒,可见阿里云的 MySQL 数据库性能还是非常强悍的
16.在 3200 万级别下的查询性能.pngimage
更多详情:https://dwz.cn/rjMkaghz

为了进一步测试性能,我们这次把数据量增加到 6400 万(同样使用快速复制 SQL),这里复制数据我们花费的时间更大。
复制完成后我们查看存储空间,数据占用了 6.0 GB,索引占用了 8.32 GB
17.查看 6400 万数据的存储量.pngimage

同样使用手机号查询数据,在 6400 万条数据中查找到 64 条数据,总共耗时 4 毫秒,和 3200 万行数据下耗时差距不大
18.在 6400 万级别数据下的查询性能.pngimage

第六步:测试阿里云 MySQL 在 1.2 亿条数据下的性能表现

在这一步我们要进一步复制数据,会发现等待的时间太长,甚至会超时,我们可以在原来的 SQL 下增加一个判断,每次复制 2000 万行数据来达到 1.2 亿条数据

insert into pre_user(name, mobile, id_no, username, balance) select name, mobile, id_no, username, balance from pre_user where id <= 20000000;

复制完成之后,我们发现数据占用了 9.48 GB,索引占用了 14.99 GB,索引存储空间远超过了数据存储空间
19.达到 1 亿级别时的存储空间.pngimage

同样我们使用手机号来查询数据,在 1.2 亿条数据下,查找 100 行数据耗时 5 毫秒,可以看见在这个数据容量下性能相当强悍,当然我们的业务数据达到了 1 亿级别时,我们采用的架构也会更加复杂。
20.精准查询数据的性能.pngimage

测试了一下 like 模糊查询,在 1.2 亿条数据下,使用 like 模糊查询(前包含)耗时 23 毫秒,基本上满足使用
21.使用 like 查询 5 万条数据.pngimage

总结

在测试的过程中,我们发现 1 核 1 G 的数据库承载能力在千万级别,我们的个人网站、小型企业网站使用低配的数据库完全满足日常需求。
8 核 16 内存的数据承载上亿的数据,查询性能也不差,对于中型企业来说,基本上也是够用了,阿里云也给我们提供了其他更加强悍的数据库。
原文地址:https://yq.aliyun.com/articles/708050?spm=a2c4e.11155435.0.0.4ad96d118locIi

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
PolarDB MySQL 5.6/MySQL 5.6升级PolarDB MySQL 8.0最佳实践
升级概述为什么选择升级到PolarDB MySQL 8.0?PolarDB MySQL 8.0.1 (基于官方MySQL 8.0.13内核版本)发布于2019-12-03和PolarDB MySQL 8.0.2(基于官方MySQL 8.0.18内核版本)发布于2020-07-22*,增强了诸多卓越的架构增强和内核能力,为业务提供更灵活的技术解决方案和强大收益的性能提升,主要包括:Serverles
49 0
PolarDB MySQL 5.7/RDS 5.7升级到PolarDB MySQL 8.0最佳实践
升级概述PolarDB MySQL 5.7/RDS 5.7 向 8.0 升级过程中,经常遇到的问题主要是性能问题、语法兼容性问题,以及周边组件是否的支持,查询的性能问题一般是由于优化器升级导致执 行计划有变,此类问题需要对性能低下的语句进行针对性的性能优化,但性能问题基本不会引发业务报错以及代码的改写问题,此类问题不在本文讨论范围之内。本文主要讨论真实的兼容性问题,此类问题需要在数据库升级过程中,
198 0
MySQL Binlog导入日志服务最佳实践
本文为您介绍使用SLS导入MySQL Binlog的使用场景和最佳实践。
131 0
「助力降本增效」RDS MySQL云盘版只读基础版发布及其最佳实践
阿里云RDS MySQL云盘版只读在原来 "高可用只读" 的基础上推出了"基础版只读"。尽管"基础版只读"在价格上比"高可用版只读"便宜了40%左右,两者对于故障的容错能力、异常的应对能力方面还是有差异的。本文通过两款产品的差异性对比,对"基础版只读"的最佳实践进行分享。
283 0
MySQL分区表最佳实践
分区是一种表的设计模式,通俗地讲表分区是将一大表,根据条件分割成若干个小表。但是对于应用程序来讲,分区的表和没有分区的表是一样的。换句话来讲,分区对于应用是透明的,只是数据库对于数据的重新整理。本篇文章给大家带来的内容是关于MySQL中分区表的介绍及使用场景,有需要的朋友可以参考一下,希望对你有所帮助。
114 0
MySQL的数值类型最佳实践
MySQL的数值类型最佳实践
69 0
MySQL行锁的最佳实践(下)
MySQL行锁的最佳实践
91 0
MySQL行锁的最佳实践(上)
MySQL行锁的最佳实践
84 0
MySQL事务隔离级别的最佳实践(下)
MySQL事务隔离级别的最佳实践(下)
79 0
+关注
stefanie燕
没有解决不了的问题,只有遇不到的问题
文章
问答
文章排行榜
最热
最新
相关电子书
更多
让 MySQL 原生分布式触手可及
立即下载
好的 MySQL 兼容可以做到什么程度
立即下载
云数据库RDS MySQL从入门到高阶
立即下载