阅读对象
本博文主要写给创业团队、技术团队人数 < 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内存数据库购买信息.
2.八核十六G内存数据库购买信息.png
第二步：初始化数据库配置、账号、数据库等
在数据库购买成功之后，阿里云会为了我们初始化创建数据库，这里需要耐心等待（博主等待了 5 分钟左右，比自己搭建 MySQL 还是快不少）
3.耐心等待数据库创建完成.png
数据库初始化完成之后我们可是开始创建账号了，这里为了测试方便，我们选择使用 root 账号并设置一个高强度的密码（生产环境不建议使用高权限 root 账号，建议使用普通账号）
4.低配的数据库创建高权限账号.png
在阿里云提供的 MySQL 在线管理工具首次使用时，我们需要设置管理工具的白名单，按照弹出的提示点击设置本实例即可
5.设置 DMS 数据管理的白名单.png
登录到 MySQL 数据库实例之后，我们需要按照以下的步骤创建数据库，这里我们以 mysql_test 命名来创建一个测试数据库
6.创建测试数据库.pngi
第三步：创建测试表以及快速生成测试数据
完成数据库创建之后，我们需要点击左上角这里选择创建的数据（若下拉框未显示，点击旁边的刷新按钮即可），
这里我们添加一些常用的字段：ID、创建时间、修改时间、姓名、手机号、身份证号、用户名、余额
7.创建用于测试的表.png
创建好表之后，我们接下来生成测试数据，阿里云的 DMS 数据管理工具提供了强大的“自动生成测试数据”功能，这里给我们带来了极大的方便。右键点击表名，在弹出的菜单中选择“自动生成测试数据”，然后我们为每个字段选择对应的生成方式（阿里云提供了强大的生成规则，可以在面板中灵活始终各种规则），生成行数这里最大可以选择到 100 万行，这里我们因为要测试上千万、上亿的数据，选择最大上限 100 万行。
8.快速生成测试数据.png
生成好了数据之后我们可以浏览生成的数据，这里可以看到生成的测试数据几乎和真实数据没有什么区别。
9.查看生成的数据.png
第四步：对 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 查看性能.png
我们为需要测试的字段增加索引（未增加索引的情况下，100 万行数据查询需要 400 毫秒，可见索引的重要性）
11.为需要测试的字段建立索引.png
索引创建好之后我们再次查询数据，在 1600 万行数据的级别下，查询返回 16 行数据总共耗时 28 毫秒，基本上可以满足使用
12.索引创建成功之后我们再次执行查询语句.png
我们分别在高配和低配的数据库上再次执行同样的查询，我们发现高配的只需要 3 毫秒，低配的也只需要 9 毫秒，这里可以看出同样的查询，第二次比第一次快两倍左右
13.两边性能比较.png
查看一下数据库的存储空间，我们发现数据占用了 1.8 GB，索引也占用了 1.8 GB，说明增加索引会增加数据库使用空间，我们应当按照最小化原则以及结合性能要求方面综合考量哪些字段应该增加索引，哪些字段不应该增加索引，一味的增加索引也会造成数据库的负担。
14.查看存储空间.png
第五步：在 3200 万条数据以及 6400 万条数据下的 MySQL 性能表现
刚才我们简单测试了一下 1600 万条数据，这里我们把数据增加到 3200 万条以及 6400 万条数据再进行这里。由于数据量过大，1 核 1 G 的数据库复制较慢，我们这里直接测试高配的数据库（同样使用之前的快速复制 SQL，执行过程等待时间较长，需要耐心等待）。
增加到 3200 万条数据时，数据占用了 3.18 GB，索引占用了 3.86 GB，数据
15.增加到 3200 万级别时的存储空间.png
我们通过常规的 SQL 按照手机号查询，在 3200 万条数据中查找 32 行数据只用了 3 毫秒，可见阿里云的 MySQL 数据库性能还是非常强悍的
16.在 3200 万级别下的查询性能.png
更多详情：https://dwz.cn/rjMkaghz
为了进一步测试性能，我们这次把数据量增加到 6400 万（同样使用快速复制 SQL），这里复制数据我们花费的时间更大。
复制完成后我们查看存储空间，数据占用了 6.0 GB，索引占用了 8.32 GB
17.查看 6400 万数据的存储量.png
同样使用手机号查询数据，在 6400 万条数据中查找到 64 条数据，总共耗时 4 毫秒，和 3200 万行数据下耗时差距不大
18.在 6400 万级别数据下的查询性能.png
第六步：测试阿里云 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 亿级别时的存储空间.png
同样我们使用手机号来查询数据，在 1.2 亿条数据下，查找 100 行数据耗时 5 毫秒，可以看见在这个数据容量下性能相当强悍，当然我们的业务数据达到了 1 亿级别时，我们采用的架构也会更加复杂。
20.精准查询数据的性能.png
测试了一下 like 模糊查询，在 1.2 亿条数据下，使用 like 模糊查询（前包含）耗时 23 毫秒，基本上满足使用
21.使用 like 查询 5 万条数据.png
总结
在测试的过程中，我们发现 1 核 1 G 的数据库承载能力在千万级别，我们的个人网站、小型企业网站使用低配的数据库完全满足日常需求。
8 核 16 内存的数据承载上亿的数据，查询性能也不差，对于中型企业来说，基本上也是够用了，阿里云也给我们提供了其他更加强悍的数据库。
原文地址：https://yq.aliyun.com/articles/708050?spm=a2c4e.11155435.0.0.4ad96d118locIi
