常见的MySQL数据库扩展方式有：

• 读写分离：这种情况适用于读远大于写的情况，读越多，就可以分出越多的从库。从库是只读的，主则负责所有的写入。主和从之间 通过同步binlog完成数据同步。

• 分表：

  • 当一张表的数据量非常大时，我们可以采取对时间，id等进行分表，对表进行瘦身，从而达到提高读取/写入速度的目的，原理 是因为，表更小了，系统维护成本更低，此外对索引的维护成本也会随之降低，但是缺点是很明显的，即当需要对所有数据进行查询时， 查询的逻辑会变得复杂。这种方案适用于并不需要所有数据的情况，例如用户的消息，只需要保存最近三个月的数据，则可以把三个月 以前的数据从当前表中抽走到其他备份表中。
  • 此外分表还有一种方式，例如用户可能有很多信息，但是常用的信息却只有那么多，我们可以把常用的信息放在用户表，其他的信息 放在其他表，通过关系把两个表关联起来，这样能加快查询的原因是可以减少很多不必要的数据查询，尤其是使用ORM的情况下，ORM 一般都会把所有的数据都拿出来以便进行映射，通过这种方式可以减少数据传输量和数据库维护表的成本。

• 分库：设想，当一个数据库的写入不堪重负时，我们该要如何处理？答案便是将一部分数据搬到另外一个数据库去，这种方案带来的好处 是显而易见的：把对其中一部分的数据的读和写都带走了，可以大大的降低数据库的负载，但是缺点便是，增加了应用程序的逻辑复杂度， 原本只要在一个数据库中连表就可以查出来的数据，现在要在不同的数据库中查找。

以上三种方案的难度依次递增，对未来的预测和预留能力要求也是依次递增。

现在出现了一些新的分布式方案，但是我还没有试过，所以没有写上去，例如 MySQL Cluster和 TiDB。

但是一般来说，合理的安排数据库的关系，合理的安排索引，合理的安排主从，在业务还没有达到那个量级之前，根本就不需要使用 更加高级的方案，目前我使用的一张表，合理的安排索引和表的关系，已经达到1.6亿行，读写分离1带3，仍然能在10ms内完成查找。