MYSQL扩展
1.业务拆分
业务发展初期为了便于快速迭代，很多应用都采用集中式的架构。随着业务规模的扩展，使系统变得越来越复杂，越来越难以维护，开发效率越来越低，并且系统的资源消耗也越来越大，通过硬件提升性能的成本也越来越高。因此，系统业务的拆分是难以避免的。
随着业务的不断发展，单个库的访问量越来越大，因此，不得不对业务进行拆分。每一块业务都使用单独的数据库来进行存储，前端不同的业务访问不同的数据库，这样原本依赖单库的服务，变成4个库同时承担压力，吞吐能力自然就提高了。
顺带说一句，业务拆分不仅仅提高了系统的可扩展性，也带来了开发工作效率的提升。原来一次简单修改，工程启动和部署可能都需要很长时间，更别说开发测试了。随着系统的拆分，单个系统复杂度降低，减轻了应用多个分支开发带来的分支合并冲突解决的麻烦，不仅大大提高了开发测试的效率，同时也提升了系统的稳定性。
2.复制策略
架构变化的同时，业务也在不断地发展，可能很快就会发现，随着访问量的不断增加，拆分后的某个库压力越来越大，马上就要达到能力的瓶颈，数据库的架构不得不再次进行变更，这时可以使用MySQL的replication(复制)策略来对系统进行扩展。
通过数据库的复制策略，可以将一台MySQL 数据库服务器中的数据复制到其他 MySQL数据库服务器上。当各台数据库服务器上都包含相同数据时，前端应用通过访问 MySQL集群中任意一台服务器，都能够读取到相同的数据，这样每台MySQL服务器所需要承担的负载就会大大降低，从而提高整个系统的承载能力，达到系统扩展的目的。
MySQL的复制可以基于一条语句(statement level)，也可以基于一条记录(row level)。通过row level的复制，可以不记录执行的SQL语句相关联的上下文信息，只需要记录数据变更的内容即可。但由于每行的变更都会被记录，这样可能会产生大量的日志内容，而使用statementlevel则只是记录修改数据的SQL语句，减少了binary log的日志量，节约了I/O成本。但是，为了让SQL语句在Slave端也能够正确地执行，它还需要记录SQL执行的上下文信息，以保证所有语句在Slave端执行时能够得到在Master端执行时的相同结果。
3.分表与分库
对于大型的互联网应用来说，数据库单表的记录行数可能达到千万级别甚至是亿级，并且数据库面临着极高的并发访问。采用 Master-Slave复制模式的MySQL架构，只能够对数据库的读进行扩展，而对数据的写入操作还是集中在Master上，并且单个Master挂载的Slave也不可能无限制多，Slave的数量受到 Master能力和负载的限制。因此，需要对数据库的吞吐能力进行进一步的扩展，以满足高并发访问与海量数据存储的需要。
Master-Slaves复制架构存在一个问题，即所谓的单点故障。当Master宕机时，系统将无法写入，而在某些特定的场景下，也可能需要Master停机，以便进行系统维护、优化或者升级。同样的道理，Master停机将导致整个系统都无法写入，直到 Master恢复，大部分情况下这显然是难以接受的。为了尽可能地降低系统停止写入的时间，最佳的方式就是采用Dual-Master架构，即Master-Master架构。