1. 增长1.1. 在高速的业务环境中，流量可能逐年增长几个数量级，环境会变得更加复杂，随之而来的数据需求也会快速增加1.2. 扩展Web服务器1.2.1. 在负载均衡的后端添加更多的服务器节点，而这通常就是扩展We b服务器的全部工作2. 可扩展性2.1. 系统支撑不断增长的流量的能力2.1.1. 可扩展性就是能够通过增加资源来提升容量的能力2.2. 一个系统扩展能力的好坏可以用成本和简单性来衡量2.3. 容量是一个和可扩展性相关的概念2.3.1. 系统容量表示在一定时间内能够完成的工作量2.3.2. 容量可以简单地被认为是处理负载的能力，从几个不同的角度来考虑负载很有帮助2.4. 系统的最大吞吐量并不等同于容量2.4.1. 如果达到最大吞吐量，则性能会下降，响应时间会变得不可接受且非常不稳定2.5. 即使系统性能不是很高也可以具备可扩展性2.6. 数据量2.6.1. 应用所能累积的大量数据是可扩展性最普遍的一个挑战2.6.2. 应用从不删除任何数据2.7. 用户数2.7.1. 当查询依赖于用户间的关系时（关系的数量可以用N*（N-1）/2来计算，这里N表示用户数2.8. 用户活跃度2.8.1. 不是所有的用户的活跃度都相同，并且用户活跃度也不总是不变的2.9. 相关数据集的大小2.9.1. 社交网站经常会面临由那些人气很旺的用户组或朋友很多的用户所带来的挑战2.10. 可扩展性的原则之一是避免节点之间的交叉访问2.11. 请专注于确定业务是读限制的还是写限制的3. 扩展MySQL的理论思想3.1. 优先使用更小的实例3.1.1. 按功能、水平方式或两者兼而有之来分割数据3.1.2. 当故障发生时，实例越小，所造成的影响面也越小3.2. 通过复制和自动写故障切换来增强弹性3.2.1. 在发生故障时，自动进行写入故障切换，并管理拓扑更改和对数据库节点的应用程序访问，以使写停机时间尽可能短3.3. 通过半同步复制保证持久性3.3.1. 相对于默认的异步复制4. 读限制与写限制工作负载4.1. 工作负载4.1.1. 系统能达到的QPS数4.1.2. 是所有类型的查询及其延迟的混合4.2. 读限制工作负载4.2.1. 读限制工作负载是指读取（SELECT）总流量超过服务器容量的工作负载4.2.2. 单源主机4.2.2.1. 增加更多应用节点可以扩展服务用户请求的客户端数4.2.2.2. 最终会被单源数据库主机的能力所限制，该数据库主机将要负责响应所有的读取请求4.2.2.3. 高CPU使用率意味着服务器正花费所有的时间处理查询4.2.2.4. CPU的使用率越高，查询的延迟也会越长4.2.3. 引入副本来扩展读流量4.3. 写限制工作负载4.3.1. 写限制工作负载则超过了服务器提供DML（INSERT、UPDATE、DELETE）操作的容量4.3.2. 当写入量成为瓶颈时，必须开始考虑使用拆分数据的方法，以便在单独的子数据集上接受并行的写入4.3.3. 仔细检查schema，确定是否存在读需求增长比其他写需求增长更快的表数据子集5. 功能拆分5.1. 基于业务中的“功能”来拆分数据是一项和业务背景强相关的任务，需要深入了解数据的用途5.2. 指导原则5.2.1. 不要根据工程团队的组织架构进行拆分，它会经常变动5.2.2. 根据业务功能来拆分表5.2.3. 不要回避处理数据中混杂了不同业务关系的问题，你不仅需要倡导数据分离，还需要倡导应用程序重构，并需要引入API来实现相互跨界的访问6. 用读池扩展读6.1. 集群中的副本可用于多个目的6.1.1. 副本是故障切换的候选对象6.2. 并非所有的复制副本都在池中，这是一种防止不同的读取工作负载相互影响的常见方法6.3. 使用读池时会有不止一台服务读请求的数据库主机6.4. 管理这些读池的一种非常常见的方法是使用负载均衡器来提供虚拟IP6.4.1. 该IP充当所有要访问读副本的流量的中介6.4.2. 技术包括HAProxy、自用主机时的硬件负载均衡器，或在公共云环境中运行时的网络负载均衡器6.5. 在MySQL中，建议使用leastconn实现池节点之间的平衡6.6. 服务发现是一个很好的选择，它可以自动发现新的主机并将其加入池列表6.7. 每个副本池至少还要有三个节点服务于特定应用6.8. 读池健康检查6.9. 选择负载均衡器算法6.9.1. 随机6.9.1.1. 负载均衡器将每个请求定向到从可用服务器池中随机选择的服务器6.9.2. 轮询6.9.2.1. 负载均衡器以重复的顺序向服务器发送请求6.9.3. 最少连接6.9.3.1. 下一个连接指向拥有最少活跃连接的服务器6.9.4. 最快响应6.9.4.1. 处理请求最快的服务器接收下一个连接6.9.5. 哈希6.9.5.1. 负载均衡器对连接的源IP地址进行哈希处理，这会将地址映射到池中的一台服务器6.9.6. 权重6.9.6.1. 负载均衡器可以组合几种算法并添加权重6.9.7. MySQL的最佳算法取决于具体工作负载6.9.7.1. 一定要考虑在特殊情况下和日常情况下会发生什么7. 排队机制7.1. 使用设计上倾向于一致性而不是可用性的数据存储来扩展写事务时，扩展应用程序层会变得复杂得多8. 使用分片扩展写8.1. 分片意味着将数据切分成不同的、更小的数据库集群8.1.1. 可以同时在更多的源主机上执行更多的写入操作8.2. 功能分割（Functional partitioning）8.2.1. 职责划分8.2.2. 将不同的节点用于不同的任务8.3. 数据分片（Data sharding）8.3.1. 当今扩展超大型MySQL应用程序最常见和最成功的方法8.4. 只对需要分片的数据进行切分8.4.1. 通常是数据集中增长非常大的部分8.5. 切分方案8.5.1. 目标是使最重要和最频繁的查询接触到尽可能少的分片8.6. 多个分片键8.6.1. 复杂的数据模型使数据分片更加困难8.7. 跨分片查询8.7.1. 主动缓存通常也是有必要的8.7.2. 设计间歇性运行的清理程序8.8. Vitess8.8.1. Vitess是面向MySQL的一个数据库集群系统8.8.2. 一个用于运行数据库层的稳定平台，而不是一个临时的解决方案8.8.3. 测试并记录向整个系统引入的延迟8.8.4. 使用金丝雀部署模型8.8.5. 特性8.8.5.1. 支持水平分片，包括数据分片8.8.5.2. 拓扑结构管理8.8.5.3. 源节点故障切换管理8.8.5.4. schema变更管理8.8.5.5. 连接池8.8.5.6. 查询重写8.8.6. 组件8.8.6.1. Vitess pod8.8.6.1.1. 对一组数据库和Vitess相关部件的通用封装8.8.6.2. VTGate8.8.6.2.1. 为应用程序与操作员控制数据库实例访问提供的服务8.8.6.3. VTTablet8.8.6.3.1. 在Vitess管理的每个数据库实例上运行的代理8.8.6.4. Topology8.8.6.4.1. 在给定的pod中保存由Vitess管理的数据库实例清单以及相应的信息8.8.6.4.2. 元数据存储8.8.6.5. vtctl8.8.6.5.1. 对Vitess pod进行操作更改的命令行工具8.8.6.6. vtctld8.8.6.6.1. 用来进行相同管理操作的图形化界面8.9. ProxySQL8.9.1. René Cannaò8.9.1.1. MySQL的长期贡献者8.9.2. 专门为MySQL协议编写的，通过通用公共许可证（GPL）发布8.9.3. 提供了一个易于部署的抽象，比HAProxy更复杂，但在基础设施和复杂性方面的前期投入较少8.9.4. 可以使用ProxySQL作为任何应用程序代码和MySQL实例的中间层8.9.5. 一个很好的轻量级中间层，而且是分片感知的，还可以相应地路由应用程序连接8.9.6. 按用户分片8.9.7. 按schema分片
