打通MySQL架构和业务的任督二脉，做个DBA高手！

在数据库实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《打通MySQL架构和业务的任督二脉，做个DBA高手！》，聊聊MySQL、架构、DBA，希望可以帮助到正在努力赚钱的你。

目前，在很多 OLTP 场景中，MySQL 数据库都有着广泛的应用，也有很多不同的使用方式。

从数据库的业务需求、架构设计、运营维护、再到扩容迁移，不同的 MySQL 架构有不同的特点，适应一定的业务场景，或者解决一定的业务问题。

DBA 作为数据库架构的设计、实施、维护人员，不仅要对各种 MySQL 架构非常熟悉，还要了解业务，对于不同的业务有一定的划分和认识，并根据业务特点和架构特点，合理选择和使用 MySQL，满足业务需求。

本文从以下三个方面对 MySQL 数据库和业务场景进行探讨和说明：

• MySQL 数据库常见架构
• 业务环境分类
• 业务与架构结合使用原则

让大家先分别对 MySQL 的架构和业务分类有所了解，然后再将两者贯通起来，使得能够在进行业务与 MySQL 架构设计时纲举目张，让用户可以用合适的技术解决支撑业务需求。

MySQL 数据库常见架构

为了对 MySQL 数据库常见架构，能够有比较清晰的认识，下面先从 MySQL 三种通用基础架构、五种特殊需求架构、架构组合与综合使用三个方面进行说明。

MySQL 三种常见基础架构

MySQL 单实例架构

MySQL 单实例，就是在服务器上部署一个 MySQL 实例来对外提供服务，这是最开始接触 MySQL 数据库会使用的方式，也是常见学习、研究 MySQL 数据库的使用方式。

MySQL 单实例的使用方式，是 MySQL 数据库使用的***阶段，通常这种情况下，MySQL 数据库与应用程序会在同一个服务器上。

这种方式主要好处就是部署和使用简单，直接通过编译安装，或者二进制包解压安装，很快就可以有一个可以使用的 MySQL 数据库环境。

同时，这种方式，依赖性少，不需要依赖其他第三方工具或者软件，维护和故障定位也比较容易。

熟悉和掌握好 MySQL 单实例环境的技能，也是维护其他 MySQL 架构的基础。

需要注意的是，MySQL 单实例在学习和开发环境可以使用一下，但这种方式的可用性和灾备性较弱，如果作为业务系统使用的数据库，尽量不要用这种方式。

MySQL master-slave 主从架构

MySQL master-slave 主从环境，是在 MySQL 单实例环境的基础上，将 MySQL 进行全库备份，再恢复出一个或多个 MySQL 实例。

通过 change maste r命令，指定新恢复出的 MySQL 实例，从那个 MySQL 节点上读取变化日志，并在本地应用，使新恢复的实例与原来的 MySQL 实例数据保持一致。

所以，原来的数据一致变化的实例，叫 master 主节点；从 master 节点获取日志，并在本地应用，使数据与 master 阶段保持一致的节点，叫 slave 从节点；这样的架构环境，就叫 master-slave 主从环境。

master-slave 主从环境，是 MySQL 数据库非常具有特色的功能，也是 MySQL 数据库应用在生产环境的常见架构。

通过 master-slave 架构，就可以使线上数据库的数据有了多份，起到了一定的数据备份功能。

Slave 从库数据变化只通过应用日志实现，一般不会主动产生写数据的情况，但可以提供对外数据读服务，这样通过增加几个 slave 从库，让只进行数据读取的业务到 slave 从库上查询，可以大大提高业务的读性能和吞吐量。

在互联网行业中，非常多的数据读操作远高于数据写操作的业务场景，通过在 master 主节点写数据，在 slave 节点上读数据，进行这种读写分离的架构，可以很好地满足业务需求。

当然，MySQL 的 master-slave 主从架构，具体实现也可以非常灵活，1 个 master 主节点，可以有 1 个或多个 slave 从节点。

而一个 slave 节点，也可以当做其他节点的 slave 节点，如果一个 slave 节点后面再有其他节点当做这个节点的 slave 从节点，就叫做级联复制。

MySQL 的 master-save 架构，在 MySQL 单实例架构的基础上，提高了 MySQL 数据库的性能、可用性和可扩展性，同时也为 MySQL 数据库追求更高的可用性，提供了基础保障。

MySQL MHA 高可用架构

虽然 MySQL 数据库的 master-salve 主从架构，使数据库有了多份，但这些 maste 主节点和 slave 从节点之间，仍然是相对独立的，尤其是 master 主节点如果出现故障了，仍然是不能对外提供数据库服务的。

为了应对各种故障和特殊情况，实现数据库更高的可用性，就需要在 master-slave 的基础上，通过其他组件来实现更高的可用性。

MySQL 高可用性的方案比较多，但目前比较主流、比较成熟的方案，还是 MySQL + MHA 高可用架构。

简单来说，为了实现更高的可用性，就要在 master-slave 主从环境的基础上，将业务连接 master 的 IP，有 master 主机的实际 IP，变成虚拟的 VIP 或者域名。

应用程序通过 VIP 访问数据库，进行数据读写，在正常情况下，业务在 master 上进行读写；如果 master 节点出现故障，高可用组件会监测到这个故障，并将 VIP 切换到 slave 从库上。

同时在 slave 从库上进行日志的传输和应用，保证 slave 上的数据，与 master 节点故障前的数据尽量一致，这样切换后新的 slave 节点就仍然可以对外提供数据库服务。

当然，对于具体实现来说，在 MySQL 的 master-slave 主从结构外，VIP 和数据库日志追平的方案也是有多种实现方式，也可进行各种深入定制，甚至一些公司不使用开源软件，直接自己开发来实现高可用组件的各个功能。

目前 MySQL + MHA 这种高可用实现方式，是比较主流和成熟的实现方式，后面也可能会有一些其他更加完善的高可用实现方式，但都可以归类到实现提高可用性这个范围。

小结：对于 MySQL 数据库的各种通用性需求，这三种基础架构都可以很好地满足，换句话说，这是 MySQL 数据库架构中必须要用到和掌握的三种基础架构。

五种特殊业务需求架构

通过 MySQL 中这三种常见基础架构，绝大多数 MySQL 数据库场景和问题，都可以很好得到满足和解决。

但一些特殊的场景，或一些特殊的问题，也可以使用除 MySQL 数据库以外的其他数据库、专门某一类或几类问题的解决方案。

针对这些特殊的业务需求，接下来我会先从要解决的问题进行描述和说明，然后再提出对应的解决方案。

MySQL + 分布式 Proxy 水平扩展架构

问题：如果业务规模进一步扩大，读写量级尤其是写的量级达到非常大的地步。

比如每秒数据写入几十万，甚至几百万，每天的数据量有几亿甚至几十亿的规模，这样的读写就远远不是一个 master 节点可以支撑的，这时就必须要进行扩展了。

一般来说，MySQL 的扩展可分为：按照不同业务进行垂直拆分的垂直扩展，和通过一定的分库分表策略实现的库表水平扩展两种方式。

这两种方式可以单独使用，也可以结合使用。但如果是解决大量数据和高并发读写，主要方式还是 MySQL 水平扩展。

MySQL 水平扩展的思路：在一个服务器上的 database 库和 table 表，总会受到一台服务器的资源限制，即使服务器的硬件各方面都达到顶配，也还是会有瓶颈。

对于业务访问来说，如果有一个 Proxy 代理层或者中间件层的一个 database 和一个 table，通过代理层按照一定的规则映射和转换，转换成底层多台服务器上的多个 database 和多个 table，这样就相当于多台服务器共同支撑一个业务，可支持的容量就与底层服务器的数量有关。

在 Proxy 代理没有到瓶颈的情况下，底层服务器数量越多，整个水平扩展集群的性能和容量也会越多，几乎可以线性扩展。通过这样的思路，就可以解决大量数据存储和并发的问题。

具体实现来说，水平扩展集群除了 MySQL 数据库，需要一个分布式 Proxy 中间件，这种水平扩展中间件种类也比较多，MySQL 官方和一些大的的公司都有开发。

我们用的比较多的是 MyCAT 中间件，对于底层的分片，可以有几十个、几百个甚至几千个。

当然，水平扩展可以解决大数据量的问题，需要有分片策略，那相应地，也会有使用这种策略的限制，比如片键选择，跨节点访问，分布式事务等问题，需要与业务进行对应结合和考虑后，才可以很好地使用。

TokuDB/MyRocks/InnoDB 高性能写入架构

问题：MySQL 数据库水平拆分，可以对于大数据量的读写进行线性扩展，相应地底层服务器数量也需要比较多。

但对于数据写入量非常大，数据读很少，数据总量大的情况，使用高性能写入架构，会更合适一些。

业务数据写入量非常大，读取量非常高的情况，一般主要对数据 insert 写入性能，同时对数据压缩效率有特别高的要求。

这种特殊的写入要求，需要对数据写入有特殊的优化和设计，并且有比较好的压缩效率和算法，能够将写入的大量数据进行压缩，节省空间。这种写入架构， 通常可以看做是 MySQL 数据库的一种特殊的存储引擎。

具体到实现而言，MySQL 的高性能写入集群，可以使用 TokuDB 存储引擎。近几年 Facebook 也开源了其内部实现的 MyRocks，可以作为高性能写入的存储引擎。

MySQL 默认的 InnoDB 存储引擎，在新的 5.7 及以后版本优化后，写入性能和压缩性能也有了更高的性能，也可以作为数据写入的一种选择。

MySQL + 缓存（Memcached、Redis等） 高并发读架构

问题：如果业务访问 MySQL 中的某一些少量热数据，访问的并发量非常高，访问的时效性，数据的一致性要求都非常高。

这时候使用 MySQL 数据库本身支持这些数据读取，可能会在并发性、时效性上出现瓶颈，所以就可以使用缓存系统结合 MySQL 来使用。

缓存系统是将 MySQL 数据库中的少量热数据存放到内存当中，由于内存的 IO 效率远高于硬盘的 IO，相应的 CPU 消耗也会少很多，这样缓存系统中响应一次业务请求的时间，会远少于直接从 MySQL 数据库访问需要的时间。

于是缓存系统就可以支撑热数据的高并发访问，数据写还是写入 MySQL 数据库中，数据读操作，优先读取缓存。

如果缓存中有，则直接从缓存中返回结果；如果缓存中没有，则从 MySQL 数据库中读取数据返回应用，并把数据结果再放到缓存的内容中。

具体实现来说，缓存系统常用的技术架构有 Memcached 和 Redis：

• Memcached 是比较经典的缓存系统，在之前常与 LAMP、LNMP 流行架构结合使用。
• Redis 是几年新兴的 Key-Value 键值型 NoSQL 数据库，除了作为缓存，还可以持久化作为 Key-Value 数据库使用。

MySQL + 小文件系统（MongoDB、Ceph等） 大字段存取架构

问题：在 MySQL 数据库中，通常是存储符合关系型数据库原理的小字段，比如数值型、字符型数据。

但在实际环境中，除了这些常用字段，还会有一些大字段，比如用户头像这种图片文件、上传的音频、视频文件、帖子内容等大 text 字段，另外还有一些 JSON 文件、XML 文件等。

这些可以以二进制形式存储在 MySQL 数据库中，但读取和管理都会比较麻烦。这时，就可以使用小文件系统来结合 MySQL 来使用。

小文件系统，是可以存储并快速访问结构化数据的系统。对于图片、音频、视频、TXT 文件、JSON 文件、XML 文件等大字段，一般就只有简单的读写操作，将这些字段存入到小文件系统中，并将对应的访问链接存入到 MySQL 数据库的表中。

这样通过数据库表，可以快速读写文件位置信息，在小文件系统中，通过文件位置信息，可以实现对大字段的快速读写访问。

具体实现而言，小文件系统也有很多技术软件，比较常见的有 MongoDB 文档型 NoSQL 数据库、Ceph 分布式小文件系统等。

MySQL + Inforbright/Greenplum 统计分析架构

问题：在 MySQL 数据库上实时响应业务需要的查询，通常是指 OLTP 业务，但对于已经产生的数据，通常会在第二天之后，有结果汇总和统计分析需求。

这类 OLAP 需求通常执行频率较低，但每次执行消耗的资源很大，如果与 OLTP 一样在一个系统上运行，就会造成这两大类业务的相互影响。这时就可以使用 MySQL 数据库与 OLAP 统计业务分类结合的架构。

MySQL 产生了业务数据后，通常需要在第二天，要对前一天的数据进行各个角度、各个维度的统计、聚合、分析，以体现和反映业务的运营情况。

这是让 MySQL 支持线上 OLTP 业务，通过数据流转程序，将每天产生的数据流转到离线的数据仓库系统中，在数据仓库系统中，进行各种数据统计分析、结果汇总，并将数据统计结果再流转到结果展示库中。这样就可以很好地实现线上 OLTP 和线下 OLAP 的结合使用和执行。

具体实现而言，对于 MySQL 数据库可以结合的 OLAP 数据仓库架构，可以选用 Inforbright 数据仓库，也可以选用 Greenplum 分布式 MPP 数据库仓库。

相对而言，Inforbright 数据仓库比较轻量级，与 MySQL 使用类似；Greenplum 分布式 MPP 数据仓库可以支撑海量数据的统计分析，功能、性能、容量等也比 Inforbright 要更强一下，成本也更大一些。

小结：MySQL 五种特殊业务架构，可以说是在 MySQL 三种常见的、通用的架构基础上，面对特殊的业务场景，遇到特殊的问题，进行针对性解决：

• 对于大量数据读写，可以采用水平扩展架构。
• 对于有大量数据写入需求，可以采用 MySQL 高性能写入架构。
• 对于热数据的高并发、快速响应的需求，可以采用 MySQL+缓存架构。
• 对于特殊的大字段存取需求，可以采用 MySQL+小文件系统架构。
• 对于离线统计分析需求，可以采用 MySQL+统计分析架构。

架构组合与综合使用

MySQL 三种比较通用的基础架构和五种特殊需求架构，都可以根据场景单独使用，也可以根据特定的场景进行组合几种架构使用，或者综合起来一起使用。

架构组合

对于只有一两种特殊情况的架构，选择基础架构和特殊架构的简单组合就可以了，生产环境中可用到的架构组合类型有：

• MySQL+MHA 高可用架构与 MySQL 分布式 Proxy 水平扩展架构组合。
• MySQL+MHA 高可用架构与 MySQL 小文件系统大字段存取架构组合。
• MySQL+MHA 高可用架构与 MySQL 缓存高并发读架构组合。
• MySQL 分布式 Proxy 水平扩展架构与 MySQL 小文件系统大字段存取架构组合。
• MySQL 分布式 Proxy 水平扩展架构与 MySQL 缓存高并发读架构组合。
• MySQL 高性能写入架构与 MySQL Inforbright/Greenplum 统计分析架构组合。

架构综合

如果是比较复杂的业务场景，几种特殊的数据库架构可以综合起来使用：

MySQL+MHA 高可用架构 、MySQL 分布式 Proxy 水平扩展架构、MySQL 缓存高并发读架构、MySQL 小文件系统大字段存取架构、MySQL  Inforbright/Greenplum 统计分析架构。

业务环境分类

***部分对 MySQL 的架构进行了说明，这是对 MySQL 数据库本身的了解，算作“知己”。

所有的数据库系统提供服务的对象都是业务系统，所以 DBA 要对业务系统进行了解，对业务的特点和适合的场景，做到心中有数，可以算作是“知彼”。做到知己知彼，就能更好地贯通两者了。

从数据库使用推导数据使用分类

从数据库操作角度看，业务系统对于数据库的操作，大的方面可以分为“读数据”和“写数据”两类。

展开来说，写数据也可以具体分为：insert 插入数据、update 修改数据、delete 删除数据三种情况。

所以，数据库的使用也可以细分为：增 insert、删 delete、改 update、查 select 四种情况。

依据业务系统对数据的操作分类，就可以对业务系统进行归类：

只读业务系统

只读是指只有查询 select，没有数据修改的情况。这种情况，是数据库中已经存在一些数据，并且这些数据只作查询或展示用，不会有任何数据变化。

比如缓存中的数据、归档后的数据、历史结果数据、统计结果数据等，都是只能进行查询和展示，不会再发生数据变化的。

可读写业务系统

按照写操作的具体情况，可以对可读写业务系统分成三类：

• 只有插入 insert，没有 update 和 delete 的可读写业务系统，这种情况是指数据表的数据只会增加，且表中的数据不能再变化，不会再有修改或者删除操作；比如操作记录表、状态变化记录表、留言记录表等。
• 有 insert 和 update，没有 delete 的可以读写业务系统，这种情况是指数据表中的数据，可以进行增加和修改，但数据一旦产生，可以变化，但不能修改。

这也是一种常见的数据库设计思路，即数据表可以有失效，但生效删除，并不是真正从数据表中删除，而是修改了表中表示状态位的列值，这样就可以保证数据一直具有可回溯性。

• insert、update、delete 都有的可读写业务系统，这种情况是指数据表中的数据可进行各种操作，可以查询，也可以进行各种变化，添删改除各种操作也都可以进行。

常见业务表分类

从业务角度对表进行分类，虽然不同的应用程序对表的使用不同，但还是能够抽象成为几大类表。

配置表

这种表通常存放业务一些基础的配置信息或者字典信息。表的数据量一般都比较小，修改变化的操作不太频繁，通常都是 select 查询操作。

状态表

这种表通常存放在业务系统中实体读象的状态信息，常见的有用户信息表，订单信息表等。这种表的数据量与实体读象的规模有直接关系，比如一个 APP 有多少注册用户，通常这个 APP 的用户表都会有多少条记录。

状态表的变化通常比较频繁，而且 insert、update、select 操作都会有，delete 操作是否有，通常会根据业务情况的规定决定。

日志表

这种表通常用来记录业务系统中某种实体的状态信息，常见的有用户登录表、充值信息记录表等。

这种表的数据规模通常比较大，而且如果业务状态变化频繁，记录的变化信息比较多，这种表的数据量和插入性能都要求比较高。

日志表的操作，通常会以 insert 操作为主，个别业务会对日志表进行查询。MySQL 五种特殊需求架构中的高性能写入架构，主要就是应用这种表的需求。

归档表

这种表，是将上面三种 OLTP 业务表的数据进行归档或者冷热分离的表。对线上业务三类表进行数据归档、冷热分离。

一方面可以控制线上业务表的数据规模，保证业务表性能；另一方面进行归档后，可用于对归档历史数据进行更好的查询反映和支持。

归档表的数据量大小与对应的线上表大小、归档周期有关。归档表的操作，除了归档过程的数据加载外，主要就是 select 查询操作了，归档后就算是只读表。

统计数据表

统计数据表，是指业务有离线统计分析需求时，需要将各种线上表和归档表的数据，通过ETL过程流转到线上 OLAP 统计分析系统中的原始数据表。

这类表通常数据量会非常大，一个 OLAP 统计分析平台会汇总多个线上业务系统的数据进行统计分析。统计数据表的操作，除了数据流转动作外，主要就是各种统计分析程序的访问计算。

统计结果表

统计结果表是在业务有离线统计分析需求时，各种统计分析过程访问统计数据表中的数据，按照一定的逻辑进行统计分析后的结果数据。

这种统计结果数据，通常数据量会比较小。统计结果表的操作，处理结果流转动作外，主要就是供访问接口进行 select 查询。

通过对业务表类型的梳理，可以对所有的业务系统进行一个大体的划分，做到心中有数。

DBA 对业务的把握

通过数据使用方式将业务系统划分为四类，再通过业务常见表类型划分，就可以对通用的业务使用数据库有一个整体的了解。但对于具体的业务场景，还需要根据每个公司具体的实际情况进行具体确认和考虑。

大多数情况下，某一种具体的业务都可以根据情况归入某一种业务类型中，只是每个业务具体的量级会有不同，大家需要先了解具体业务环境中的量级，再根据业务类型与 MySQL 架构的使用情况，进行对应就可以了。

如果实际环境中确认有不在现有分类中的情况，则可以通过现有的思路，进行新的类型划分和架构对应。

业务与架构结合使用原则

上面两部分通过对 MySQL 各种架构进行说明，并通过对业务环境的分类，可以让大家对 MySQL 架构和业务环境本身有一定的了解。

下面我将就我在架构设计和运维当中两者结合的使用原则，对 MySQL 业务和架构的结合使用进行说明。

适用性原则

适用性原则就是在考虑某一个具体业务场景具体使用哪一种或者几种业务场景时，我们要尽量使用合适的技术架构解决合适的问题。

需求与场景

MySQL 的三种通用基础架构，适用的场景多一些。但通用业务场景在数据量级、访问规模、读写方式等发生比较大的变化时，就变成了有特殊需求的场景，可以考虑使用某种特定场景对应的 MySQL 架构技术，尽量保证适用性。

反之，如果实际业务在量级、规模、读写方式还没有达到非常特殊的场景时，尽量使用通用的基础架构就可以满足业务需求，也可以降低系统复杂度和隐患。

整体与部分

不论对于一个业务系统，还是 MySQL 数据库架构而言，都要从整体和部分两个角度进行看待和考虑。

一个业务系统，首先是一个整体，从整体上看各种业务需求和使用方式，把握好整体，然后再考虑具体的需求。

如果没有特殊的需求，则可以按照通用场景来设计和考虑；如果某一部分有特殊的需求，则可以把这部分内容单独划分出来，进行对应的架构设计。

多个通用和特殊的架构，相互组合，完成一个对业务系统支撑的架构总体。

稳定与升级

一般情况下，业务系统都是先用通用架构进行数据支持，在通用架构适用时，业务系统也可以稳定运行。

在业务系统不断运行过程中，有新业务场景需求产生时，要综合考虑保证现有业务稳定性、以及升级业务系统到新架构的步骤和阶段。

一般不要一下子全部升级，建议采用先测试、再上线、分批次逐步过渡和升级的方式。

阶段性原则

业务系统的发展是有阶段的，MySQL 数据库架构的发展也是有阶段的。不同阶段关注的信息和主要处理思路都是不同的，从不同维度考虑阶段性也是使用架构和业务的重要原则。

数量阶段

数量是一个比较明显的阶段判断指标。业务系统通常会有 DAU、UV、PV 等指标，来帮助判断业务系统的规模。

数据库系统、QPS、TPS、一个表的数据量、一个库下的表数量、一个实例下的库数量、总的实例数量、服务器数量，都是与架构结合比较紧密的指标。

以表数据量举例：如果一个表运行一年，数量在 10 万以下，就可以认为是小表了；数据量在 10 万-1000 万以上的，可以认为是中表。

数据量在 1000 万以上，就可以认为是大表，这时就需要考虑归档或水平拆分了；如果数据量在 1 亿以上，就必须要用特殊架构进行单独处理了。

统一组织

在业务规模和数据规模都比较小的时候，若存在多种不同的架构，还是可以维护的。

但如果数据库实例数量和业务模块都大起来之后，统一一种或少数几种数据架构就非常重要了。统一架构组织，可以让业务系统和架构，更加容易控制和维护。

规模控制

业务发展到一定规模，底层架构中的数据库都必须要控制规模，一个实例不能太大，一个表也不能太大，如果超过了约定好的规模，需要进行实力拆分，或者表拆分，以使实例和库表都保持在统一设定的规模当中。

扩展性原则

应用业务随着时间会不断变化，底层的 MySQL 架构也需要随着业务的变化能够具有一定的扩展性，保持变化和扩展的空间，以不断支持业务的发展。

架构之间的打通

从 MySQL 的三种基础架构就可以看出来，MySQL 单实例架构→MySQL master-slave 主从架构→MySQL MHA 高可用架构，这中间是逐步演进的，有直接的依赖关系。

后续 Oracle 推出的 InnoDB Cluster 架构，也与这些基础架构有直接演进关系。

其他五种特殊需求的架构，随着业务分类的变化，特殊情况也可能发生变化，可根据这些变化从一种特殊架构调整成为另一种特殊的架构。

OLTP 与 OLAP

数据库系统一般分为 OLTP 和 OLAP 两大类，但实际在目前的业务系统和架构设计中，这两种需求都是需要支持的。

只要建立好一个比较稳定、可靠的数据流转体系，将这两者打通，就可以很容易地实现 OLTP 和 OLAP 的互通，OLTP 的业务数据传送到 OLAP 中进行统计，OLAP 的统计结果，再返回到 OLTP 中进行展示。

新架构的使用

MySQL 架构中除了常见的三种基础架构和五种特殊架构，还有一些新的技术和趋势来尝试完善和解决现有架构的一些问题，比如 InnoDB Cluster 等技术，对 MySQL 的扩展和高可用会有更好的解决方式。

虽然目前这些新技术还没有完全稳定和成熟，但在后续新技术架构稳定成熟后，可以很容易地将现有架构扩展成新的技术架构，这样就可以更好地解决业务问题了。

后记

本文尝试从 MySQL 架构，业务环境分类，MySQL 业务和架构结合使用原则三个方面对 MySQL 架构和业务进行了说明。

希望能够从架构角度让大家对架构和业务的理解，能够更深一层、触类旁通地面对和解决各种业务问题。

其中某些与架构关联性不太大的具体细节，在本文中没有完全展开，会在以后的文章中再进行说明。

作者：赵飞祥

介绍：现在竞技世界从事数据库相关工作， Oracle 10G OCP，11G OCM，Oracle YEP 年轻专家，8 年数据库运维和架构经验，对 MySQL、Oracle、PostgreSQL、Greenplum、MongoDB 等多种常见数据库有丰富的运维实践经验，掌握与数据库相关的前后端架构和 DevOps 实现技术，擅长数据库架构设计、维护优化、数据流转、Shell 和 Python 开发；乐于技术交流，以网名 yumushui 进行了大量的技术总结和思考分享。

理论要掌握，实操不能落！以上关于《打通MySQL架构和业务的任督二脉，做个DBA高手！》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！