此贴用于扫盲。
===============================
【分表】
（下面说到的内容都是基于“按照关系型数据库的第三范式要求应该在同一个表的”的情况）
分表，最直白的意思，就是将一个表结构分为多个表，分表后，可以存在于同一个库里，也可以放到不同的库。
【为什么要分表？】
保证单表的容量不会太大，从而来保证单表的查询等处理能力。例如单表记录条数达到百万到千万级别时就要使用分表。
【分表方式？】
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亿记录
心里有一个数了，按业务做规划还是比较容易的。
----------------------------------------------------------------