MySQL分库分表会带来哪些问题？

当必要全局独一的64位ID时，执行：

REPLACE INTO sequence (stub) VALUES ('a');  
SELECT LAST_INSERT_ID();  

这两条语句是Connection级此外，select last_insert_id() 必需与 replace into 在统一数据库毗连下才气获得方才插入的新ID。

行使replace into取代insert into甜头是停止了表行数过大，不必要其它按期整理。

此方案较为简朴，但弱点也明明：存在单点题目，强依靠DB，当DB非常时，整个体系都不行用。设置主从可以增进可用性，但当主库挂了，主从切换时，数据同等性在非凡环境下难以担保。其它机能瓶颈限定在单台MySQL的读写机能。

flickr团队行使的一种主键天生存策，与上面的sequence表方案相同，但更好的办理了单点和机能瓶颈的题目。

这一方案的整体头脑是：成立2个以上的全局ID天生的处事器，每个处事器上只陈设一个数据库，每个库有一张sequence表用于记录当前全局ID。表中ID增添的步长是库的数目，起始值依次错开，这样能将ID的天生散列到各个数据库上。如下图所示：

由两个数据库处事器天生ID，配置差异的auto_increment值。第一台sequence的起始值为1，每次步长增添2，另一台的sequence起始值为2，每次步长增添也是2。功效第一台天生的ID都是奇数(1, 3, 5, 7 ...)，第二台天生的ID都是偶数(2, 4, 6, 8 ...)。

这种方案将天生ID的压力匀称漫衍在两台呆板上。同时提供了体系容错，第一台呈现了错误，可以自动切换到第二台呆板上获取ID。但有以下几个弱点：体系添加呆板，程度扩展时较伟大;每次获取ID都要读写一次DB，DB的压力照旧很大，只能靠堆呆板来晋升机能。

可以基于flickr的方案继承优化，行使批量的方法低落数据库的写压力，每次获取一段区间的ID号段，用完之后再去数据库获取，可以大大减轻数据库的压力。如下图所示：

照旧行使两台DB担保可用性，数据库中只存储当前的最大ID。ID天生处事每次批量拉取6个ID，先将max_id修改为5，当应用会见ID天生处事时，就不必要会见数据库，从号段缓存中依次派发0~5的ID。当这些ID发完后，再将max_id修改为11，下次就能派发6~11的ID。于是，数据库的压力低落为原本的1/6。

3)Snowflake漫衍式自增ID算法

Twitter的snowflake算法办理了漫衍式体系生玉成局ID的需求，天生64位的Long型数字，构成部门：

• 第一位未行使
• 接下来41位是毫秒级时刻，41位的长度可以暗示69年的时刻
• 5位datacenterId，5位workerId。10位的长度最多支持陈设1024个节点
• 最后12位是毫秒内的计数，12位的计数次序号支持每个节点每毫秒发生4096个ID序列

这样的甜头是：毫秒数在高位，天生的ID整体上定时刻趋势递增;不依靠第三方体系，不变性和服从较高，理论上QPS约为409.6w/s(1000*2^12)，而且整个漫衍式体系内不会发生ID碰撞;可按照自身营业机动分派bit位。

不敷就在于：强依靠呆板时钟，假如时钟回拨，则也许导致天生ID一再。

综上

团结数据库和snowflake的独一ID方案，可以参考业界较为成熟的解法：Leaf——美团点评漫衍式ID天生体系，并思量到了高可用、容灾、漫衍式下时钟等题目。

5、数据迁徙、扩容题目

当营业高速成长，面对机能和存储的瓶颈时，才会思量分片计划，此时就不行停止的必要思量汗青数据迁徙的题目。一样平常做法是先读出汗青数据，然后按指定的分片法则再将数据写入到各个分片节点中。另外还必要按照当前的数据量和QPS，以及营业成长的速率，举办容量筹划，推算出或许必要几多分片(一样平常提议单个分片上的单表数据量不高出1000W)

假如回收数值范畴分片，只必要添加节点就可以举办扩容了，不必要对分片数据迁徙。假如回收的是数值取模分片，则思量后期的扩容题目就相比拟力贫困。

【编辑保举】

1. 怎样停止回表查询？什么是索引包围？ | 1分钟MySQL优化系列
2. 数据库集群方案及Oracle RAC架构说明
3. 数据库软件架构，到底要计划些什么？
4. 微处事架构下必要什么样的数据库
5. 说明两个主机和Oracle数据库巡检剧本，值得保藏

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!