14 分区表：哪些场景我不建议用分区表？前面几讲，我们通过索引的原理，索引覆盖的使用，结合复杂 SQL的调优，学习了索引设计的各个方面。那么在模块二的最后一讲，我想来谈谈分区表的设计，用来对数据进行物理分区。 分区表即涉及表结构设计，也涉及了索引的设计，以及一个数据库上的哲学问题：是否要使用分区表？ 接下来，我们就来学习分区表的相关知识（分区表的使用、注意事项、误区）以及在业

16 读写分离设计：复制延迟？其实是你用错了上一讲我们学习了主从复制的原理，以及 4 种不同复制类型在不同业务中的选型，今天我们来看一下主从复制延迟的问题。 很多同学会发现，自己的主从复制会存在主从数据延迟的问题，甚至会导致读写分离，架构设计在业务层出现较为严重的问题，比如迟迟无法读取到主库已经插入的数据。 但这可能并不是 MySQL 复制的问题，而是你的业务没有根据 MyS

15 MySQL 复制：最简单也最容易配置出错从今天开始，我们正式进入高可用架构的设计环节。 在前两个模块中，我们学习了 MySQL 架构中的表结构设计、索引设计。对业务开发的同学来说，掌握这些内容已经能很好地面向业务逻辑进行编码工作了。 但是业务需要上线，所以除了表和索引的结构设计之外，你还要做好高可用的设计。因为在真实的生产环境下，如果发生物理硬件故障，没有搭建高可用架构

18 金融级高可用架构：必不可少的数据核对在 17 讲中，我们学习了高可用的三大架构设计，基于数据层的高可用、基于业务层的高可用，以及融合的高可用架构设计。 在这些架构中，仅仅解决了业务连续性的问题：也就是当服务器因为各种原因，发生宕机，导致MySQL数据库不可用之后，快速恢复业务。但对有状态的数据库服务来说，在一些核心业务系统中，比如电商、金融等，还要保证数据一致性。 这里

17 高可用设计：你怎么活用三大架构方案？我们前面学习了 MySQL 数据库复制的原理、优化，以及基于复制技术实现业务层的读写分离方案，这些内容都是为了铺垫 MySQL数据库的高可用架构设计。因为复制是高可用的基础，但只用复制同步数据又远远不够，你还要结合自己的业务进行高可用设计。 同时，高可用也不仅仅是数据库的事情，你要从业务的全流程出发，思考怎么设计一个真正健壮的高可用架

19 高可用套件：选择这么多，你该如何选？在 17、18 讲中，我们已经学习了 MySQL数据库的高可用解决方案，并且学习了怎么根据金融业务的要求，通过无损半同步复制的方式进行三园区的同城容灾设计，以及三地务中心的跨城容灾设计。 但是当数据库发生宕机时，MySQL 的主从复制并不会自动地切换，这需要高可用套件对数据库主从进行管理。 这一讲，我们就来学习 MySQL 常用的高可

21 数据库备份：备份文件也要检查！在前几讲中，我们学习了高可用的架构设计。你要牢记：高可用只是用来保证业务的连续性，当发生灾难时，MySQL 数据库可以进行切换（比如 20 讲基于复制或者InnoDB Cluster 技术的高可用解决方案）。 除了高可用设计外，对架构师来说，还要做好备份架构的设计。因为我们要防范意外情况的发生，比如黑客删除了数据库中所有的核心数据；又或者某

20 InnoDB Cluster：改变历史的新产品前面几讲，我们围绕 MySQL 复制技术构建了读写分离方案、数据库高可用解决方案，以及数据库的管理平台。可以看到，我们所有的讨论都是基于 MySQL的复制技术。 不过，MySQL 复制只是一种数据同步技术，如果要完成数据库的高可用解决方案，还要额外依赖外部的组件，比如MHA、Orchestrator、数据库管理平台等。 另一

22 分布式数据库架构：彻底理解什么叫分布式数据库前面的三个模块里，我们学习了 MySQL 架构设计中最核心的内容，表结构设计、索引设计、高可用设计。相信通过前面的内容，你已经能很好地完成 MySQL数据库的架构设计工作。 从这个模块开始，我们将进入架构设计的深水区，学习分布式数据库架构的设计。 我们都知道，现在互联网应用已经普及，数据量不断增大。对淘宝、美团、百度等互联网业

23 分布式数据库表结构设计：如何正确地将数据分片？前面 22 讲中，我们简单学习了分布式数据库的架构，知道各类分布式数据库都离不开计算层、存储层、元数据层这三层关系。 另外，很重要的一点是，知道分布式数据库是把数据打散存储在一个个分片中。在基于MySQL 的分布式数据库架构中，分片就存在于 MySQL 实例中。 今天这一讲，我们来学习分布式数据库中，一个非常重要的设计：正确