qq_41549632的博客

《sharding-jdbc 分库分表的 4种分片策略》 中我们介绍了 sharding-jdbc 4种分片策略的使用场景，可以满足基础的分片功能开发，这篇我们来看看分库分表后，应该如何为分片表生成全局唯一的主键 ID。 引入任何一种技术都是存在风险的，分库分表当然也不例外，除非库、表数据量持续增加，大到一定程度，以至于现有高可用架构已无法支撑，否则不建议大家做分库分表，因为做了数据分片后，你会发现自己踏上了一段踩坑之路，而分布式主键 ID 就是遇到的第一个坑。 不同数据节点间生成全局唯一主键是个棘手的问题

昨天中午在食堂，和部门的技术大牛们坐在一桌吃饭，作为一个卑微技术渣仔默默的吃着饭，听大佬们高谈阔论，研究各种高端技术，我TM也想说话可实在插不上嘴。 聊着聊着突然说到他上午面试了一个工作6年的程序员，表情挺复杂，他说：我看他简历写着熟悉SQL语句调优，就问了下 Explain 执行计划怎么看？结果这老哥一问三不知，工作6年这么基础的东西都不了解！ 感受到了大佬的王之鄙视，回到工位我就开始默默写这个，哎~ 我TM也不太懂 Explain ，老哥你这是针对我啊！哭唧唧~ Explain有什么用 当Explai

往下开展前先做个答疑，前两天有个小伙伴私下问了个问题说： 如果我一部分表做了分库分表，另一部分未做分库分表的表怎么处理？怎么才能正常访问？ 这是一个比较典型的问题，我们知道分库分表是针对某些数据量持续大幅增长的表，比如用户表、订单表等，而不是一刀切将全部表都做分片。那么不分片的表和分片的表如何划分，一般有两种解决方案。 严格划分功能库，分片的库与不分片的库剥离开，业务代码中按需切换数据源访问 设置默认数据源，以 Sharding-JDBC 为例，不给未分片表设置分片规则，它们就不会执行，因为找不到路由

一、Sharding-JDBC 简介 Sharding-JDBC 最早是当当网内部使用的一款分库分表框架，到2017年的时候才开始对外开源，这几年在大量社区贡献者的不断迭代下，功能也逐渐完善，现已更名为 ShardingSphere，2020年4⽉16⽇正式成为 Apache 软件基⾦会的顶级项⽬。 随着版本的不断更迭 ShardingSphere 的核心功能也变得多元化起来。从最开始 Sharding-JDBC 1.0 版本只有数据分片，到 Sharding-JDBC 2.0 版本开始支持数据库治理（注册