受群里小伙伴之邀，搞一个分库分表案例，这样让很多没用过分库分表的心里也有个底，不然永远看到的都是网上的各种概念和解决方案性的文章。
创新互联公司长期为1000+客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为偃师企业提供专业的成都网站建设、成都网站制作，偃师网站改版等技术服务。拥有十载丰富建站经验和众多成功案例,为您定制开发。
由于用户表过于庞大，采取相关SQL优化，还是不能满足，所以现对其进行做分库分表。
数据库： my-sharding
数据库表： t_user
建表语句如下：
关于数据库分库分表通常有两种方案：
下面我们来演示水平拆分，大致思路：
加入有2000万条数据，那么为了方便演示，我们就暂定分为五个库，每个数据库对应五个表。
五个数据库：
每个数据库有五张表：
建表语句如下：
使用技术栈： JDK8 + MySQL + Spring Boot + Mybatis + Shardingsphere + Druid
maven 相关依赖：
配置文件相关配置如下：
分库分表的两个分片类：
下面是业务部分代码，先看 UserMapper.xml 内容：
UserMapper 接口：
为了更好地演示，我这里加入了 controller 层和 service 层，这也是大家平常开发套路。
service 层代码如下：
controller层代码如下：
最后是项目的启动类：
启动项目，启动成功：
下面我们来演示一下新增数据和查询。
先来添加数据到数据库中，这里使用的是IDEA中restful工具：
后台日志：
再查看数据库表中：
到此，我们的数据依旧落库，下面我们来演示一下数据查询。
浏览器里输入：
返回数据：
后台日志：
从日志和返回结果可以看出，已经为我们正确的选择到对应的数据库和表了，这样，一个分库分表的查询就成功了。
本文没有太多的概念，直接使用案例演示。相关概念性的文章，还有分库分表解决方案的文章，网上一堆堆的，感兴趣可以自行查阅。
Twitter-Snowflake算法产生的背景相当简单，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的id，这些id还需要一些大致的顺序（方便客户端排序），并且在分布式系统中不同机器产生的id必须不同。各种主键ID生成策略对比，见 常见分布式主键ID生成策略
把 41位的时间前缀 ， 10位的节点标识 ， 12位的sequence 组合在一起。
除了最高位bit标记为不可用以外，其余三组bit占位均可浮动，看具体的业务需求而定。 默认情况下41bit的时间戳，1970年算起可以支持该算法使用到2038年，10bit的工作机器id可以支持1024台机器，序列号支持1毫秒产生4096个自增序列id 。
Snowflake是Twitter在2010年用Scala语言写的一套主键生成策略，用Thrift对外发布主键生成服务，其中依赖了Twitter内部的Infrastructure，后来Twitter用 Twitter-server 代替了Snowflake，自2012年起就未更新。见 Twitter-Snowflake项目地址（Tags:snowflake-2010）
之前写了一个Java的实现，改自网上一个版本: Twitter的分布式自增ID算法Snowflake实现分析及其Java、Php和Python版 。后来看到当当网的 Sharding-JDBC 分库分表中间件已实现了此算法。就直接在其中添加了一些新特性，已merge。( 具体实现 , 说明文档 )
添加3种IdGenerator实现。
用笔记本（i7-3632QM 2.2GHz 四核八线程）测试了下，每秒生成409万（理论上的峰值），CPU占用率18.5%。
musql分库分表后java用Mybatis可以很方便的实现分库分表，比如有几个数据源，每个库对应一个数据源，然后配置好负责读写的路由和表的配置，保证读写的数据库一致性就可以了
可以按照时间划分库，或者按照账户数量等，在一张表里面存储账户对应的库名，然后每次操作库的时候从内存中通过账户id获取库名，表名应该是统一的，只是对应的表明前缀不一样而已（前缀是根据账户id或者一定规则开头，后半部分应该都一样的）
水平分表的话，200张，你应该按照实际需求去做，因为200毕竟不是一个小数目，首先举个例子，就像电话号码，130开头的一张表，131开头的一张表，但是你这个具体就不知道了，还有就是例如按照单数双数分也可，然后最好是按照主键列去分表会比较合乎规范。
重庆分公司
重庆分公司
