mysql关于数据库表的水平拆分和垂直拆分

最初知道水平垂直分表的时候是刚参加工作不久的时候,知道了这个概念,但是公司用户量和数据量始终没上来,所以也没用到过,知道有一天到了一家新公司后,这些才被应用到实际开发中,这里我就大概说说关于水平和垂直的拆分.

分表的概念还是比较好理解的,就拿本网站的评论表展开讲讲,源于数据量较大,当评论表有CURD操作时,单张表表现的可能有些力不从心,当然这里还能引申出关于读写速度的其他好多概念:数据库读写分离,NoSql等等.

垂直拆分:
顾名思义是将表垂直着给拆掉,即:(下面是省略掉字段的一个表)
  1. +--------+---------+--------+--------+-------+---------+---------+--------+-----+-------------+--------+-----------+------+--------+ 
  2. | userid | groupid | areaid | amount | point | modelid | message | islock | vip | overduedate | siteid | connectid | from | mobile | 
  3. +--------+---------+--------+--------+-------+---------+---------+--------+-----+-------------+--------+-----------+------+--------+ 
  4. |      1 |       5 |      0 |   0.00 |    50 |      10 |       0 |      0 |   1 |           0 |      1 |           |      |        | 
  5. +--------+---------+--------+--------+-------+---------+---------+--------+-----+-------------+--------+-----------+------+--------+ 

比如说一个用户表有很多的属性,关联了很多数据,如果放到同一个表里面的话查询是方便了,但是效率不行,所以这里就是用到了垂直拆表:
拆成如下:

  1. +--------+---------+--------+--------+-------+---------+---------+
  2. | userid | groupid | areaid | amount | point | modelid | message |
  3. +--------+---------+--------+--------+-------+---------+---------+ 
  4. |      1 |       5 |      0 |   0.00 |    50 |      10 |       0 |   
  5. +--------+---------+--------+--------+-------+---------+---------+
  6.  
  7. 和 
  8.  
  9. +--------+--------+-----+-------------+--------+-----------+------+--------+ 
  10. | userid | islock | vip | overduedate | siteid | connectid | from | mobile | 
  11. +--------+--------+-----+-------------+--------+-----------+------+--------+ 
  12. |      1 |      0 |   1 |           0 |      1 |           |      |        | 
  13. +--------+--------+-----+-------------+--------+-----------+------+--------+ 
  • 把常用的字段放一个表,不常用的放一个表
  • 把字段比较大的比如text的字段拆出来放一个表里面
  • 使用的话是根据具体业务来拆,查询时使用多表联查,可以再配合redis存储
水平拆分:
顾名思义是将表数据水平的拆掉,即:
  1. 表0 user_0 
  2. +--------+---------+--------+--------+-------+---------+---------+ 
  3. | userid | groupid | areaid | amount | point | modelid | message | 
  4. +--------+---------+--------+--------+-------+---------+---------+ 
  5. |      1 |       5 |      0 |   0.00 |    50 |      10 |       0 |   
  6. +--------+---------+--------+--------+-------+---------+---------+ 
  7. 表1 user_1 
  8. +--------+---------+--------+--------+-------+---------+---------+ 
  9. | userid | groupid | areaid | amount | point | modelid | message | 
  10. +--------+---------+--------+--------+-------+---------+---------+ 
  11. |      1 |       5 |      0 |   0.00 |    50 |      10 |       0 |   
  12. +--------+---------+--------+--------+-------+---------+---------+ 
  13. 表2 user_2 
  14. +--------+---------+--------+--------+-------+---------+---------+ 
  15. | userid | groupid | areaid | amount | point | modelid | message | 
  16. +--------+---------+--------+--------+-------+---------+---------+ 
  17. |      1 |       5 |      0 |   0.00 |    50 |      10 |       0 |   
  18. +--------+---------+--------+--------+-------+---------+---------+ 
  19. 表9 user_9 
  20. +--------+---------+--------+--------+-------+---------+---------+ 
  21. | userid | groupid | areaid | amount | point | modelid | message | 
  22. +--------+---------+--------+--------+-------+---------+---------+ 
  23. |      1 |       5 |      0 |   0.00 |    50 |      10 |       0 |   
  24. +--------+---------+--------+--------+-------+---------+---------+ 
  25.  
当然这里不一定要0-9一共10张表来表示,通常情况下使用"取模"的形式来将数据进行表的存储,如果用4张表那么就是id%4 结果会是0,1,2,3四种,user_0,user_1,user_2,user_3就够了,具体这里就要看表的数据量了.
对水平分表的数据进行CURD操作也是一样,之前根据id取模算出当前数据在哪张表中,然后再select * from user_"取的模",这里有人要问了,我添加数据之前都不知道数据库的id,更不能进行取模了,怎么找到对应的表添加啊,对了,这里就需要一张临时表,临时表的作用就是提供数据插入的自增id,得到自增id后再通过取模进行分表插入.
水平分表的表结构是一样的,只是去掉了自增的属性.

这里不得不说水平分表的另一种形式,就是不是通过取模计算的分表,而是user_0存数10w条数据,存满创建新表user_1,继续存储在user_1,存满创建user_2一直存储并新建下去,个人建议这种分表使用场景是user_1的数据为历史数据,访问需求量会慢慢减小,而新表的数据访问量是很高的.

在这里我想说的就是:"根据业务需求进行分表,不为业务服务的架构都是耍流氓".

 

原文博客链接:http://www.yigangwu.com/index.php?m=content&c=index&a=show&catid=33&id=59  点击打开链接

原文地址:https://www.cnblogs.com/behindman/p/8727495.html