互联网发展至今，各个公司企业的数据量都大幅增长，分库分表越来越多的被我们用到，那么我们应该如何针对我们自己的业务场景，对数据进行合理的划分，用最小的代价解决掉性能瓶颈。

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第11天，点击查看活动详情 概述 分库分表后设计到的第一个问题就是，如何选择路由key，应该如何对key进行路由。路由key应该在每

上一篇文章《Mysql分库分表》中介绍了为啥要分库分表及对应的策略，但是也会引发一系列的问题，本文就来介绍“分布式事务问题”怎么解决。

前面文章在谈论分布式唯一ID生成的时候，有提到雪花算法，这一次，我们详细点讲解，只讲它。 SnowFlake算法 核心思想：分布式，唯一。 算法具体介绍 雪花算法是 64 位 的二进制，一共包含了四部

雪花算法的原始版本是scala版，用于生成分布式ID（纯数字，时间顺序）,订单编号等。 1bit，不用，因为二进制中最高位是符号位，1表示负数，0表示正数。生成的id一般都是用整数，所以最高位固定为0。 41bit-时间戳，用来记录时间戳，毫秒级。 ，减1是因为可表示的数值范围…

今天我们介绍一下 Sharding-JDBC框架和快速的搭建一个分库分表案例，为讲解后续功能点准备好环境。 Sharding-JDBC 最早是当当网内部使用的一款分库分表框架，到2017年的时候才开始对外开源，这几年在大量社区贡献者的不断迭代下，功能也逐渐完善，现已更名为 Sh…

先说一下为什么要分表 当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。

最终不得已改动了一下源码才趟过去(其实就是注释了一行代码). 假设有以上三个分表, 分表逻辑用orderId取模, 即orderId=0的写到order_00,orderId=1的写到order_01,orderId=2的写到order_02. 用过sharding-jdbc的…

分库分表的文章网上非常多，但是大多内容比较零散，以讲解知识点为主，没有完整地说明一个大表的切分、新架构设计、上线的完整过程。因此，我结合去年做的一个大型分库分表项目，来复盘一下完整的分库分表从架构设计