随着时间和业务发展，数据库数据量不可控，造成表中数据越来越多，此时再进行CRUD操作的话，会造成很大的性能问题，比如查询实时数据，表数据达到了千万级别，要求一分钟查询一次，但你一个select就要耗时2两分钟才能执行完，这岂不是很尴尬。
利用这一原理，如上图要查询全局第二页数据，limit 2 offset 2 改写为 limit 1 offset 1，每个分库偏移 1，获取1条数据 ，得到的数据集的并集，那么结果为【3，4】基本能够认为，是全局数据的limit 2 offset 2的数据，当然这里只是为了所以返回的准确数据，但是实际并不是精准的。
从最开始 Sharding-JDBC 1.0 版本只有数据分片，到 Sharding-JDBC 2.0 版本开始支持数据库治理，再到 Sharding-JDBC 3.0版本又加分布式事务 ，如今已经迭代到了 Sharding-JDBC 4.0 版本。比如将订单表 t_order 拆分成 t_order_0 ··· t_order_9 等 10张表。
转载至我的博客 为什么越来越多公司使用TIDB ，而不分库分表了 - 架构成长指南 ，公众号：架构成长指南当我们使用 Mysql数据库到达一定量级以后，性能就会逐步下降，而解决此类问题，常用的手段就是引入数据库中间件进行分库分表处理，比如使用 Mycat、ShadingShper
本文目录：介绍什么是分库分表；为什么要分库分表；怎么做分库分表，小米是如何实现的；如何进行数据迁移。分库分表遇到的问题；分库分表的下一代解决方案；介绍什么是分库分表，为什么要分库分表；介绍分库分表之前，要说下数据库架构的演进过程。
前言分库分表是解决单库单表性能瓶颈的有效手段，但也会引入新的复杂性和技术挑战。这篇文章跟大家一起聊聊，分库分表后带来的7个问题，以及相关的解决方案，希望对你会有所帮助。一、全局唯一 ID 问题1、问题描述在分库分表后，每张表的自增 ID 只在本表范围内唯一，但无法保证全局唯一。
