数据库优化之分表

说明

• 单表数据量大，这时分成多个表，并行查询
• 单表字段内容大，将大字段分离到另一个表，减少第一个表io
• 建议超500万以上再做分表，而却精良将表放在不同物理机上，这时会出现不同数据库事物的问题，所以复杂度也就高了，所以分表需要全面考虑分表后的优势是否大于劣势

• 分割方式

• 垂直分割

垂直分割适用于记录不是非常多的，但是字段却很多，这样占用空间比较大，检索时需要执行大量的I/O，严重降低了性能，这个时候需要把大的自读那拆分到另一个表中，并且该表与源表时一对一关系。
垂直分割比较常见：
例如博客系统中的文章表，比如文章tbl_articles(id, titile, summary, content, user_id, create_time)，因为文章中的内容content字段可能会比较长，如果放在tbl_articles中会严重影响文章表的查询速度，所以将内容放到tbl_articles_detail(article_id, content)，像文章列表只需要查询tbl_articles中的字段即可，如果想要查询文章的具体内容就关联tbl_articles_detail，
像我们经常看到的tbl_order表有对应的tbl_order_detail, 就是减少order字段的数量，将一些使用频率相对较低的放在detail详情表中
垂直拆分的优点： 可以使得行数据变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分区可以简化表的结构，易于维护。
垂直拆分的缺点： 主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。此外，垂直分区会让事务变得更加复杂。

水平分割

水平拆分是指数据表行的拆分，表的行数超过500万行或者单表容量超过10GB时，查询就会变慢，这时可以把一张的表的数据拆成多张表来存放。水平分表尽可能使每张表的数据量相当，比较均匀。举个例子：我们可以将用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响。
水品拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题，但由于表的数据还是在同一台机器上，其实对于提升MySQL并发能力没有什么意义，所以水品拆分最好分库。
水平拆分能够支持非常大的数据量存储，应用端改造也少，但分片事务难以解决，跨界点Join性能较差，逻辑复杂。
水平拆分会给应用增加复杂度，它通常在查询是需要多个表名，查询所有数据需要union操作。在许多数据库应用中，这种复杂性会超过它带来的优点，因为只要索引关键字不大，则在索引用于查询时，表中增加2-3倍数据量，查询时也就增加读一个索引层的磁盘次数，所以水平拆分要考虑数据量的增长速度，根据实际情况决定是否需要对表进行水平拆分。

水平分割方案

水平分割最重要的是找到分割的标准，不同的表应根据业务找出不同的标准

用户表可以根据用户的手机号段进行分割如user183、user150、user153、user189等，每个号段就是一张表
用户表也可以根据用户的id进行分割，加入分3张表user0,user1,user2，如果用户的id%3=0就查询user0表，如果用户的id%3=1就查询user1表
对于订单表可以按照订单的时间进行分表

数据库分片方案

客户端代理： 分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现。 当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。

中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat、360的Atlas、网易的DDB等等都是这种架构的实现。

创建中间表

有时我们基于基础表，查询后分析出我们需要的结果后，在进行业务之间调用，
那么为什么不把这些分析结果单独存在一个中间表中这样我们直接差中间表，
然后定时去分析原表后再插入中间表也是一种变相的垂直分表

参考：数据库分表