【资料整理】分库&分表

      此贴用于扫盲。

=============================== 

【分表】

（下面说到的内容都是基于“按照关系型数据库的第三范式要求应该在同一个表的”的情况）

       分表，最直白的意思，就是将一个表结构分为多个表，分表后，可以存在于同一个库里，也可以放到不同的库。

【为什么要分表？】

        保证单表的容量不会太大，从而来保证单表的查询等处理能力。例如单表记录条数达到百万到千万级别时就要使用分表。

【分表方式？】

1.纵向分表

根据数据的活跃度进行拆分。

2.横向分表

把大的表结构，横向切割为同样结构的不同表。

冷数据：变化频率慢，查询次数多的数据。冷数据使用 myisam 可以有更好的查询性能。对冷数据，可以配置更多的从库，因为大部分操作是查询，可以加快查询速度。

活跃数据：统计信息，或者变化频率比较高的数据。活跃数据可以使用 innodb ，可以有更好的更新速度。对热数据，可以相对有更多的横向分表处理。

===============================

【分库】

【为什么要分库？】

       随着数据量增加也许单台db的存储空间不够，随着查询量的增加单台数据库服务器已经没办法支撑。

【单库单表 -> 单库多表 -> 多库多表】

       例如，有一张用户(user)表放在数据库db中，所有的用户都可以在db库中的user表中查到。随着用户数量的增加，user表的数据量会越来越大，当数据量达到一定程度的时候对user表的查询会渐渐的变慢，从而影响整个db的性能。可以通过某种方式将user进行水平的切分，产生表结构完全一样的user_0000,user_0001等表。随着数据量增加也许单台db的存储空间不够，随着查询量的增加单台数据库服务器已经没办法支撑。这个时候可以再对库进行水平切分。

【分库分表产生的问题及注意事项】

1.分库分表维度的问题

       假如用户购买了商品,需要将交易记录保存取来，如果按照用户的纬度分表，则每个用户的交易记录都保存在同一表中，所以很快很方便的查找到某用户的购买情况，但是某商品被购买的情况则很有可能分布在多张表中，查找起来比较麻烦。反之，按照商品维度分表，可以很方便的查找到此商品的购买情况，但要查找到买人的交易记录比较麻烦。

所以常见的解决方式有：

     a.通过扫表的方式解决，此方法基本不可能，效率太低了。

     b.记录两份数据，一份按照用户纬度分表，一份按照商品维度分表。

     c.通过搜索引擎解决，但如果实时性要求很高，又得关系到实时搜索。

2.联合查询的问题

       联合查询基本不可能，因为关联的表有可能不在同一数据库中。

3.避免跨库事务

       避免在一个事务中修改db0中的表的时候同时修改db1中的表，一个是操作起来更复杂，效率也会有一定影响。

4.尽量把同一组数据放到同一db服务器上

       例如将卖家a的商品和交易信息都放到db0中，当db1挂了的时候，卖家a相关的东西可以正常使用。也就是说避免数据库中的数据依赖另一数据库中的数据。

----------------------------------------------

下面这片短文中谈到mysql的问题，贴出来看看。

【mysql使用为什么要分库分表】

http://www.thinksaas.cn/group/topic/26653/

可以用说用到mysql的地方，只要数据量一大,，马上就会遇到一个问题：要分库分表。

这里引出一个问题：为什么要分库分表呢？mysql处理不了大表吗？

       其实是可以处理的大表的。在我所经历的项目中，单表在物理上的文件大小为80g左右，单表记录数在5亿以上，而且这个表属于一个非常核心的表：朋友关系表。

       但这种方式可以说不是一个最佳方式。因为面临某些文件系统时 - 如ext3文件系统 - 在对大文件的处理上会有许多问题。

       这个层面可以用xfs文件系统进行替换。但mysql单表太大后有一个问题是不好解决: 表结构调整相关的操作基本不在可能。所以大项目在实际使用中都会面临着分库分表的应用。

       从innodb本身来讲数据文件的btree上只有两个锁，叶子节点锁和子节点锁。可想而知，当发生页拆分或是添加新叶时都会造成表里不能写入数据。

所以分库分表就是一个比较好的选择了。 那么分库分表多少合适呢?

       经测试，在单表1000万条记录以下，写入读取性能是比较好的。如果再留点buffer，那么单表全是数据字型数据的可以保持在800万条记录以下，有字符型的单表可以保持在500万以下。

如果按100库100表来规划，如用户业务:

500万*100*100 = 50000000万 = 5000亿记录

心里有一个数了，按业务做规划还是比较容易的。

----------------------------------------------------------------