tencent cloud

具备优异性能和扩展能力的数据库可帮助您迅速提高原有系统的负载能力，在同等数据库规模下合理使用 MySQL 可帮助您提高数据库的并发能力，支撑更高的业务每秒访问次数。

1. 选择适合自己的数据库配置

1.1 选择数据库版本

云数据库 MySQL 目前提供完全兼容原生 MySQL 的5.5、5.6、5.7、8.0版本，建议您选择5.6或更高的版本，它们提供了更稳定的数据库内核，优化改进5.5及更老版本的设计以提升系统的性能，并提供了多项极具吸引力的新特性。

本文以 MySQL 5.7 为例介绍新版本特性。MySQL 5.7 具有被普遍认可的高性能、可靠性和易用性。它部分优化点和新特性如下：

• 原生 JSON 支持
  MySQL 5.7 新增了一种数据类型，用来在 MySQL 的表中存储 JSON 格式的数据。原生支持 JSON 数据类型主要有如下好处：
• 文档校验：只有符合 JSON 规范数据段才能被写入类型为 JSON 的列中，所以相当于有了自动 JSON 语法校验。
• 高效访问：当您在一个 JSON 类型的列中存储 JSON 文档的时候，数据不会被视为纯文本进行存储。实际上，数据用一种优化后的二进制格式进行存储，以便可以更快速地访问其对象成员和数组元素。
• 性能提升：可以在 JSON 类型列的数据上创建索引以提升 query 性能。这种索引可以由在虚拟列上所建的“函数索引”来实现。
• 便捷：针对 JSON 类型列附加的内联语法可以非常自然地在 SQL 语句中集成文档查询。例如 features，feature 是一个 JSON 字段：

   SELECT feature->"$.properties.STREET" AS property_street FROM features WHERE id = 121254;
  

使用 MySQL 5.7 可以在一个工具中无缝地混合最好的关系和文档范例，在不同的应用和使用案例中应用关系型范例或文档型范例当中最适合的范例。这为 MySQL 用户极大扩大了应用范围。

• SYS Schema
  MySQL SYS Schema 是一个由一系列对象（视图、存储过程、存储方法、表和触发器）组成的 database schema，使存储在 Performance Schema 和 INFORMATION_SCHEMA 的各类表中的监测数据资源，可以通过方便、可读、对 DBA 和开发者的友好的方式进行访问。
  MySQL SYS Schema 默认包含在 MySQL 5.7 中，并提供摘要视图以回答诸如下面所列的常见问题：
• 谁占了数据库服务的所有资源?
• 哪些主机对数据库服务器的访问量最大?
• 实例上的内存都上哪去了?
• InnoDB 相关改进
• InnoDB 在线操作（Online DDL）：您可以在不重启 MySQL 的情况下，动态地调整您的 Buffer Pool size 以适应需求的改变。现在 InnoDB 也可以在线自动清空 InnoDB 的 UNDO 日志和表空间，消除了产生大共享表空间文件 （ibdata1）问题的一个常见原因。最后，MySQL 5.7 支持重命名索引和修改 varchar 的大小，这两项操作在之前的版本中，都需要重建索引或表。
• InnoDB 原生分区：在 MySQL 5.7 InnoDB 中包含了对分区的原生支持。InnoDB 原生分区会降低负载，减少多达90%的内存需求。
• InnoDB 缓存预热：当 MySQL 重启时，InnoDB 自动保留您缓存池中最热的25%的数据。您再也不需要任何预加载或预热您数据缓存的工作，也不需要承担 MySQL 重启带来的性能损失。

MySQL 5.7 更多优化和新特性可参见 MySQL 官方资料。

1.2 选择实例规格（数据库内存）

当前 MySQL 并未提供单独的 CPU 选项，CPU 将根据内存规格按比例分配。您可以根据自己的业务特征购买相应的数据库规格，我们为每一种实例都做了详尽的标准化测试以为您提供选型时的性能参考。
但需要注意的是，Sysbench 标准化测试并不能代表所有的业务场景，建议您在将业务正式运行在 MySQL 之前对数据库做一次压力测试，以便于更加了解 MySQL 在您的业务场景下的性能表现。请参见 MySQL 性能说明。

内存是实例的核心指标之一，访问速度远远大于磁盘。通常情况下，内存中缓存的数据越多，数据库的响应就越快；如果内存较小，当数据超过一定量后，就会被刷新到磁盘上，如果新的请求再次访问该数据，就要从磁盘上把它从磁盘中读取进内存，消耗磁盘 IO，这个时候数据库响应就会变慢。

对于读并发较大或读延迟较为敏感的业务，建议您不要选择过小的内存规格，以保障数据库的性能。

1.3 选择硬盘

云数据库 MySQL 实例的硬盘空间包括数据文件、系统文件、binlog 文件、临时文件。在写入的数据量超出实例硬盘空间时，如未及时升级，可能会触发实例锁定。因此在选购硬盘空间时，建议您对未来一段时间内可能的数据量增长保留一定冗余，避免因硬盘容量不足引起的实例锁定或频繁升级。

1.4 选择适合您的数据复制方式

云数据库 MySQL 提供了异步、半同步、强同步三种复制方式，请参见 数据库实例复制方式，如您的业务对写入时延或数据库性能较为敏感，建议您选择异步复制方式。

1.5 云数据库的高可用

云数据库 MySQL 采用主备 M-S（主备模式）的高可用架构，其主备之间的数据同步依靠 binlog 日志的方式。同时支持将实例恢复到任何一个时间点，这个功能需要依靠运用备份和日志。因此，通常情况下您无需再搭建备份恢复系统或付出其他额外支出来保障实例的高可用。

1.6 云数据库的扩展性

云数据库 MySQL 的数据库版本、内存/硬盘规格均支持在线的动态热升级。升级过程不会中断您的业务，您无需担心业务规模增长带来的数据库瓶颈。

1.7 将 CVM 和 MySQL 配合使用

通常情况下，在购买成功后您需要将云服务器 CVM 和 MySQL 配合使用，请参见 使用 CVM 访问 MySQL。

2. 使用只读实例作为读扩展

在常见的互联网业务中，数据库读写比例通常为4:1至10:1之间。在这类业务场景下，数据库的读负载远高于写负载，在遇到性能瓶颈时一个常见的解决方案就是增加读负载。
MySQL 只读实例为您提供了读扩展解决方案，请参见 只读实例。
只读实例也可应用于不同业务的只读访问中，例如，主实例承担在线业务读写访问，只读实例为内部业务或数据分析平台提供只读查询。

3. 云数据库的灾备方案

云数据库 MySQL 提供了 灾备实例 帮助您一键搭建跨城域的异地数据库灾备。

使用灾备实例，可实现多地域之间不同机房互为冗余，当一个机房发生故障或由于不可抗因素导致无法提供服务，快速切换到另外一个机房。灾备实例使用腾讯内网专线做数据同步，且经过 MySQL 的内核级复制优化，尽可能消除灾难情况下同步延迟给业务带来的影响，在异地业务逻辑就绪的情况下，可以达到秒级别的灾备切换。

4. 两地三中心方案

使用云数据库 MySQL，仅需在页面简单配置几步即可实现两地三中心方案：

• 购买 MySQL 同城强一致性集群，选择 多可用区部署（灰度开放），提供一地两中心能力。
• 为该集群添加异地灾备节点，即可实现两地三中心架构。

5. 使用灾备实例为用户提供就近接入

灾备实例采用独立 M-S（主备模式）的高可用架构，同时可对外提供只读的访问能力。因此，如有需要跨地域的用户就近接入业务场景，您可放心使用灾备实例。