mysql 分表 条件查询,面试过关斩将：分库分表-sharding-jdbc分页，排序，条件查询优化...

之前讲了利用sharding-jdbc 3.1进行分表的情况，也讲了利用一致性hash去做分表的高可用。今天讲下分表后的分页，排序，条件查询优化。

其实本身sharding-jdbc是提供了分页功能的，我们方便期间是可以直接用的，但是不推荐用它。亲测翻页深度越深性能消耗越大，慢到让你抓狂。

简单介绍下他的分页原理，不做太多讲解：

分页和排序都用到了结果归并器：

排序

举例 我们的sql是 select * from user u order u.id desc;

然后被sql路由改写成如下sql：

select * from user_0 u order u.id desc;

select * from user_1 u order u.id desc;

查询出结果后然后各自存入队列，然后两个队列再进行比较，再排序。这种方式类似流的方式比较，性能上它已经做了最大的优化，时间复杂度是O(n) ，可想而知如果有100W数据，需要处理多久这个大家自己猜吧 哈哈。

分页

我们先理解 select u.* from user u limit100000,10 MySQL本身的查询器是先跳过前100000数据，然后再取10条数，其实本身性能就开始下降了。

然后经过sharding-jdbc的sql路由改写成如下sql：

select * from user_0 u limit 0,100010;

select * from user_1 u limit 0,100010;

然后查出结果再在归并器里处理，这样的性能很难让人接受。

条件查询：

直接就实现不了，是不是欲哭无泪？

解决办法：

解决办法一般都放弃使用它自身的这种排序或者分页，使用nosql工具如 MongoDB，es，solr等创建二级索引。

比如我们利用es，把我们常用的搜索条件和排序字段都索引进去，这样我们先查询es,然后返回id(分表策略选取的id),然后再拿这个id去各个表中查询，性能也完全没有问题。如果该id在各个表中刚好是主键，那性能会非常快，因为主键不但是唯一索引，更因为是聚簇索引，聚簇索引上面存的是该列数据。

关于MongoDB，es的使用和优化后面会讲到，MySQL的索引优化及索引使用也会讲到

如果觉着写的不好请多指教，也可以给我留言。如果觉着对你有帮助也请持续关注哈。

也可以动下你的小手指分享一下呀

面试过关斩将：分库分表终极问题解答-高可用方案：一致性hash

面试过关斩将：分库分表终极问题解答-拆表方案sharding-jdbc