【分库分表三部曲精华】

1.何为分库分表？分库分表的类型有哪些？哪些场景使用？各自的优缺点是？

彻底搞清分库分表（垂直分库，垂直分表，水平分库，水平分表）https://mp.weixin.qq.com/s?__biz=MzA5Mzg4MDg0Ng==&mid=2648851078&idx=1&sn=9bb2ad7e1e91179d6dd721fb860b5b30&chksm=8841f5e7bf367cf15fdf131786774d48d2f2e2e226e318c5d7a20bc366fc7fa25afd6d9397a5&scene=21#wechat_redirect

总结
垂直分表：可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失。

垂直分库：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。

水平分库：可以把一个表的数据(按数据行)分到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题(数据路由问题后边介绍)。

水平分表：可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化。

一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。

2.如何分库分表原理？【高并发的话推荐使用雪花算法生成唯一分布式ID】。

分库分表之后，id 主键如何处理？如何保持全局唯一https://mp.weixin.qq.com/s/jAbUD-iGAcoZb0rMjsF8Awphp简洁版雪花算法Snowflake_myeye520的博客-CSDN博客_php 雪花算法原理介绍：Snowflake的核心思想是将64bit的二进制数字分成若干部分，每一部分都存储有特定含义的数据，比如说时间戳、机房ID、机器ID、序列号等等，最终生成全局唯一的有序ID。它的标准算法是这样的：0 0000000000000000000000000000000000000000 0000000000 000000000000符号位 41位时间戳，大约够69年 10位(机房+机器ID) 12位序列号 具体位数怎么分配https://blog.csdn.net/myeye520/article/details/122243057

总结：
1、数据库自增长ID

这个就是说你的系统里每次得到一个 id，都是往一个库的一个表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表里去写入。

这个方案的好处就是方便简单，谁都会用；

缺点就是单库生成自增 id，要是高并发的话，就会有瓶颈的；如果你硬是要改进一下，那么就专门开一个服务出来，这个服务每次就拿到当前 id 最大值，然后自己递增几个 id，一次性返回一批 id，然后再把当前最大 id 值修改成递增几个 id 之后的一个值；但是无论如何都是基于单个数据库。

适合的场景：你分库分表就俩原因，要不就是单库并发太高，要不就是单库数据量太大；除非是你并发不高，但是数据量太大导致的分库分表扩容，你可以用这个方案，因为可能每秒最高并发最多就几百，那么就走单独的一个库和表生成自增主键即可。



2、Redis生成ID

通过Redis的INCR/INCRBY自增原子操作命令，能保证生成的ID肯定是唯一有序的，本质上实现方式与数据库一致。

适用场景：比较适合计数场景，如用户访问量，订单流水号（日期+流水号）等。

缺点：Redis实例或集群宕机后，找回最新的ID值比较麻烦。

优点：整体吞吐量比数据库要高。



3.雪花算法生成分布式唯一ID，snowflake 算法相对其他三个方法来说还是比较靠谱的，要是搞分布式 id 生成，如果是高并发的，那么建议采用这个应该性能比较好，一般每秒几万并发的场景，足够用了。有个时钟回拨问题可以通过判断一下每次请求的时间是否比上一次时间大，小的话说明回拨了，需要等待一下再判断大于再生成ID。

3.如何实战分库分表呢？

MySQL分表后，你一直都在关心：如何查询呢？https://mp.weixin.qq.com/s?__biz=MzA5Mzg4MDg0Ng==&mid=2648851087&idx=1&sn=b46ea3455fcd8b920df6ffdda4e9f23b&chksm=8841f5eebf367cf835b0a3cccf9ddef25f777f2466667196c58e5da06b617b96b35744376d8d&scene=21#wechat_redirect4.项目中常见的真实的分库分表一般如何规划呢？

分库：

1）按功能分

用户类库、商品类库、订单类库、日志类、统计类库...

2）按地区分

每个城市或省市一个同样的库，加上后缀或前缀如：db_click_bj、db_click_sh...


分表：

1、横向分表 解决表记录太大问题

1）按某个字段分

如：discuz的附件表分成10个附件分表pre_forum_attachment_0到pre_forum_attachment_9，还有1个附件索引表pre_forum_attachment存储tid和附件id关系。

根据主题的tid最后一位来决定附件要保存在哪个分表。


2）按日期分表

一些日志、统计类的可以按年、月、日、周分表

如：点击量统计click_201601、click_201602



3）使用mysql的merge

先把分表创建好，然后创建总表指定engine= MERGE UNION=(table1,table2) INSERT_METHOD = LAST;



2、纵向分表 解决列过多问题

1）经常组合查询的列放在一个表，常用字段的表可考虑Memory引擎

2）不经常使用的字段单独成表

3）把text、blob等大字段拆分放在附表

如：phpcms的文章表分成主表v9_news和从表v9_news_data，主表存标题、关键字、浏览量等，从表存具体内容、模板等

终极总结：

分库分表注意事项：

1、维度问题

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

所以常见的解决方式有：

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

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

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

2、避免分表join操作 因为关联的表有可能不在同一数据库中

3、避免跨库事务

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

4、分表宜多不宜少；这样做主要是为了尽量避免后期可能遇到的二次拆分

5、尽量把同一组数据放到同一DB服务器上

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