分布式方案

分库&拆表方案

基本认识

用分库&拆表是解决数据库容量问题的唯一途径。

分库&拆表也是解决性能压力的最优选择。

分库 – 不同的数据表放到不同的数据库服务器中（也可能是虚拟服务器） 拆表 – 一张数据表拆成多张数据表，可能位于同一台服务器，也可能位于多台服务器（含虚拟服务器）。

去关联化原则

摘除数据表之间的关联，是分库的基础工作。

摘除关联的目的是，当数据表分布到不同服务器时，查询请求容易分发和处理。 学会理解反范式数据结构设计，所谓反范式，第一要点是不用外键，不允许Join操作，不允许任何需要跨越两个表的查询请求。第二要点是适度冗余减少查询请求，比如说，信息表，fromuid, touid, message字段外，还需要一个fromuname字段记录用户名，这样查询者通过touid查询后，能够立即得到发信人的用户名，而无需进行另一个数据表的查询。

去关联化处理会带来额外的考虑，比如说，某一个数据表内容的修改，对另一个数据表的影响。这一点需要在程序或其他途径去考虑。

分库方案

安全性拆分

将高安全性数据与低安全性数据分库，这样的好处第一是便于维护，第二是高安全性数据的数据库参数配置可以以安全优先，而低安全性数据的参数配置以性能优先。参见运维优化相关部分。

顺序写数据与随机读写数据分库

顺序数据与随机数据区分存储地址，保证物理i/o优化。这个实话说，我只听说了概念，还没学会怎么实践。

基于业务逻辑拆分

根据数据表的内容构成，业务逻辑拆分，便于日常维护和前端调用。

基于业务逻辑拆分，可以减少前端应用请求发送到不同数据库服务器的频次，从而减少链接开销。

基于业务逻辑拆分，可保留部分数据关联，前端web工程师可在限度范围内执行关联查询。

基于负载压力拆分

基于负载压力对数据结构拆分，便于直接将负载分担给不同的服务器。 基于负载压力拆分，可能拆分后的数据库包含不同业务类型的数据表，日常维护会有一定的烦恼。

分表方案

数据量过大或者访问压力过大的数据表需要切分

忙闲分表

单数据表字段过多，可将频繁更新的整数数据与非频繁更新的字符串数据切分 范例 user表 ，个人简介，地址，QQ号，联系方式，头像 这些字段为字符