一、概述
构建高可扩展系统的重要原则：在系统内尽量避免串行化和交互。
如果将应用所有的数据简单地放到单个MySQL服务器实例上，则无法很好的扩展，迟早会碰到性能瓶颈。传统的方法是购买更多强悍的机器，也就是常说的“垂直扩展”或“向上扩展”。另一个方法是将任务分配到多台计算机上，这通常被称为“水平扩展”或“向外扩展”，最后，大部分应用还会有一些很少或者从不需要的数据，这些数据可以被清理或归档。这个方法称为“向内扩展”。
?
二、规划可扩展性
考虑以下问题，帮助规划可扩展性：
- 应用的功能完成了多少？
- 预期的最大负载时多少？
- 如果依赖系统的每个部分来分担负载，在某个部分失效时会发生什么？
为扩展赢得时间：
在扩展之前可以先优化性能。
比如更换高性能存储引擎、创建高性能索引、优化查询性能、优化服务器配置、优化操作系统和硬件等。
?
三、扩展
1、向上扩展
建议使用MySQL5.5或更新的版本，或者Percona Server5.1及后续版本。当前合理的“收益递减点”的机器配置大约是256GB RAM，32核CPU以及一个PCIE flash驱动器。
用更高配置的机器，MySQL的性能也提升不了多少了。
?
2、向外扩展
向外扩展策略划分为三个部分：复制、拆分、以及数据分片。
?
2.1、复制
最简单也最常见的向外扩展的方法是通过复制将数据分发到多个服务器上，然后将备库用于读查询。这种技术对于以读为主的应用很有效。
?
2.2、按功能拆分
将独立的服务器或节点分配给不同的应用，这样每个节点只包含它的特定应用所需要的数据。
如门户网站常常把把不同的栏目放在一起，可以浏览网站新闻、论坛，寻求支持和访问知识库等，这些不同功能区域的数据可以放到专用的MySQL服务器中。
这种分布数据的方法并不高效，不能通过功能划分来无限地进行扩展。
?
2.3、数据分片
目前用于大型MySQL应用的方案中，数据分片是最通用且最成功的方法。
很难将应用从单一数据存储转化为分片架构。如果在应用设计初期就已经预计到分片，那实现起来就容易的多。
分片数据存储看起来是优雅的解决方案，但很难实现。如非必要，尽量不分片。如果想扩展写容量，就必须切分数据。
?
2.3.1、选择分区键
我们目标是对那些最重要并且频繁查询的数据减少分片。这其中最重要的是如何为数据选择一个活多个分区键。分区键决定了每一个分配到哪一个分片中。确定分区键一个比较好的办法是用实体-关系图，或一个等效的能显示所有实体及其关系的工具来展示数据模型。尽量把关联的实体靠的更近。
选择分区键的时候，尽可能选择那些能够皮面分片查询的，但同时也要让分片足够小。如果可能应该期望分片尽可能同样小，这样在为不同数量的分片进行分组时能够很容易平衡。
应用拥有多个分区键，特别是存在两个货更多“维度”的时候，某些数据在系统内至少需要存储两份，但这并不意味着需要去设计两个完全冗余的数据存储，可以存储两份记录主键和分区键，其他内容通过再查询获取。
?
2.3.2、跨分片查询
大多数分片应用多少都有一些查询需要对多个分片的数据进行聚合或关联操作。一条跨分片查询实际上需要拆分成多条并行执行的查询，每个没偏上执行一条。一个设计良好的数据库抽象层能够减轻这个问题，但类似的查询仍然会比分片内查询要慢并且梗加昂贵，所以通常会更加依赖缓存。
跨分片查询也可以借助汇总表来执行。
未分片的数据通常存储在全局节点中，可以使用缓存来分担负载。
跨分片查询并不是数据分片面临的唯一难题，维护数据一致性同样困难。
?
2.3.3、分配数据、分片和节点
分片和节点不一定是一对一的关系，应该尽可能地让分片的大小比节点容量小很多，这样就可以在单个节点上存储多个分片。保持分片足够小更容易管理，这将使数据的备份和恢复更加容易，如果表很小，那么像更改表结构这样的v奥做回更加容易。小一点的分片也便于转移。
我们说“易于管理的大小”是指保持表足够小，以便能在5或10分钟内提供日常的维护工作，如ALTER TABLE、CHECK TABLE或者OPTIMIZE TABLE。
如果将分片设置的太小，会产生太多表，这可能引发文件系统或MySQL内部结构的问题。另外太小的分片还会导致跨分片查询增多。
?
2.3.4、在节点上部署分片
在节点上部署分片通常有一些办法，推荐使用每个分片一个数据库的方式，并把分片号卸载数据库名和表明中。如：bookclub_23.comments_23。
这样会增加例如ALERT TABLE这类操作的负责杜，但也有一些优点：
- 如果分片全部在一个数据库中，转移分片会比较容易。
- 因为数据库本身是文件系统中的一个目录，所以可以很方便的管理一个分片的文件。
- 如果分片互不关联，则很容易查看分片的大小。
- 全局唯一表明可避免误操作。
?
3.3.5、分配
将数据分配到分片中有两种主要的方
