• 1. Mysql分库分表
  • 2. 数据切分,顾名思义,就是数据分散,将一台主机上的数据分摊到多台,减轻单台主机的负载压力,有两种切分方式,一种是分库,即按照业务模块分多个库,每个库中的表不一样,还有一种就是分表,按照一定的业务规则或者逻辑将数据拆分到不同的主机上,每个主机上的表是一样的,这个有点类似于Oracle的表分区。 
  • 3. 分库分表的由来 单库单表 单库单表是最常见的数据库设计,例如,有一张用户(user)表放在数据库db中,所有的用户都可以在db库中的user表中查到。
  • 4. 单库多表 随着用户数量的增加,user表的数据量会越来越大,当需要添加一列的时候,mysql会锁表,期间所有的读写操作只能等待。严重影响性能。可以通过某种方式将user进行水平的切分,产生两个表结构完全一样的user0,user1等表,这些表刚好是一份完整的数据。
  • 5. 多库多表          随着数据量增加也许单台DB的存储空间不够,随着查询量的增加单台数据库服务器已经没办法支撑。这个时候进行分库又叫垂直分区。
  • 6. 商品分库分表示意图:
  • 7. 商品表的规则: 根据SellerGoodsId进行分库分表,每个表存在100w个记录,共5个库500张表。 其他分库分表方式: 1:日期方式,它的特点就是离散性加周期性, 如每周进行分表,每年进行分库的方式,一般用于一些日志的记录 2: mod方式,如一个表的主键对5取余数
  • 8. 一些缺陷: 商城: 因为发布商品是随机存储到某库某表,于是一个卖家的商品分散到很多数据库上,理想状态最好是一个卖家的所有商品都在一张表上,便于查询。 其他方式: 当一个表或库的数据量增长到了一个极限,要加库或加表的时候,这种分库分表算法的离散性,必需要做数据迁移才能完成。
  • 9. 商城分库分表标签T:后面的表名为一张大表,正式SQL中,该表名会被替换成实际表名,比如:{T:tbSellerGoods} I:后面的字段为分库分表的依据字段,比如: {I:lSellerGoodsId} C:后面的字段名为Count(*)的别名,比如: {C:nCount} G:后面的字段名为Group by的字段名,比如: {G:nA} O:Order By的写法,后面为字段名 排序方式, {O:nA desc}或者 {O:nA},比如select * from tbA {O:nA desc} L:Limit,后面的写法为 开始记录序号 记录个数,比如: {L:nFromIndex nRecordCount}或者{L:0 40}或者{L:0 nRecordCount},记录号从0开始 B:批量操作,写法为{B:lId,1,2,3},where lId={B:lId,1,2,3} S:后面的表名为一张大表,正式SQL中,该表名会被剔除,比如: {S:tbA}
  • 10. 商品操作过程
  • 11. 对商城商品表分库分表的一些想法
  • 12. 初步方案: 1,根据SellerId进行分库分表,每一个SellerId的商品都在同一个表中,方便查询。 2,当SellerId第一次发布商品的时候,在关联表(tbSellerPosition)中添加一条数据并放入memcache,用于记录SellerId所在的库和表。 3, SellerGoodsId由系统毫秒时间+随机(10000000)+SellerId组合。 4,如果当某一个表中的SellerId商品过多,则迁移到新库新表或其他压力比较小的库和表
  • 13. 按SellerId进行分库分表(初步方案)
  • 14. (本页无文本内容)
  • 15. 平衡方案: 1,根据SellerId进行分库,SellerGoodsId分表。 2,当SellerId第一次发布商品的时候,在关联表(tbSellerPosition)中添加一条数据并放入memcache,用于记录SellerId所在的库。 3, SellerGoodsId由自增id+SellerId组合,其中自增id用于定位当表。 4,每一个库的表结构都是相同的,为了方便进行数据迁移而且不影响SellerGoodsId的正常使用。 5,当某一个库中的数据远远大于其他库的时候,根据SellerId导入到新增的数据库
  • 16. (本页无文本内容)
  • 17. (本页无文本内容)
  • 18. 从下面几个方面对这3个方案进行对比: 1:数据库数据分布均匀情况 2:按经销商进行列表查询 3:按经销商数据迁移 4:其他方面
  • 19. (本页无文本内容)
  • 20. 商城方案:应需要在5个库查询,需要5个数据库连接并且每个连接在100表进行遍历,效率最低初步方案:因都在一个表中,只需在一个表中查询即可平衡方案:和初步方案比较,就是需要在100个表中遍历
  • 21. 商城方案:数据没有规律可言,按经销商进行数据迁移,执行效率最低,并且因不在一个数据库中,也需要为每一个数据库写对应的存储过程平衡方案比初步方案而言,后者只需在一个表中搜索,前者需要遍历100个表
  • 22. 跨库当某个SellerId的所拥有的数据非常大,需要进行数据迁移需要根据SellerId去关联表查询当前所在库表数据分散在每一个库每一个表
  • 23. 我的结论: 1,对于同一个SellerId的商品,可以进行聚合,分页和排序操作。 2,没有完美的分库分表方式,只有最适合当前需求的方式。
  • 24. Thank you