本篇文章给大家谈谈当数据库扼住系统性能咽喉，直接分库分表能解决吗，以及不建议分库分表对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

本文目录

1. MySQL分库分表有哪些成熟的中间件不要破坏到原有程序设计的
2. 当数据库扼住系统性能咽喉，直接分库分表能解决吗
3. 分库分表的几种常见玩法及如何解决跨库查询问题
4. 分库分表思路与解决方案

MySQL分库分表有哪些成熟的中间件不要破坏到原有程序设计的

假如你想了解的话，那么建议从mycat入手。但具体想落地那不同的系统架构方案也不一样。

推荐一些目前实用的：

Java

用hibernate可以试试hibernateshards

或者

HiveDB也可以是一个选择。

想了解更多，后续可以补充。

当数据库扼住系统性能咽喉，直接分库分表能解决吗

分库分表是比较靠后的优化手段，因为成本比较高。

遇到数据库瓶颈:

-首先考虑sql优化，这是最简单的方法。对现有系统基本没有影响。

-其次就是考虑数据库的读写分离，这也是相对简单的方法。在数据库层面进行配置，系统层面只需要调整一下获取数据库连接的逻辑。读数据时即可以获取主库连接，也可以获取从库连接。写数据时只获取主库连接。

-再考虑增加缓存层。将数据缓存到缓存中，当再次访问时不再从数据库获取。一般缓存层对系统是透明的，基本对系统本身没有影响。但是引入缓存，也引入了相应的需要考虑的问题，比如雪崩，命中率，分布式缓存等

-还有一种非技术手段，就是改需求。引起性能问题的原因是否是需求不合理？或者需求太复杂？是否可以简化需求？此方法对系统的影响也相对较小。

-最后才考虑分库分表。优先分库，因为相对分表更简单。将对应的表移动到新库，调整系统获取数据库连接的逻辑。这里需要考虑要移动哪些表，在提高性能的前提下，首先尽量避免分布式事务。

-最最后，考虑分表。分表的主要原因是单表数据量太大。分表又分纵切和横切。纵切就是按列切，比如用户表，常用信息为基本信息表，其它信息为详情表。横切就是按行切，比如一亿数据量的表切分为十张一千万的表。这里就涉及数据该存放到哪张表，或从哪张表里取。分表后又可以分库，来进一步优化。

-如果涉及到分布式事务，又要考虑如何保证分布式事务。理论方面2pc，3pc，paxos，cap，base。对应的中间件的使用。

对系统的设计和优化不是人云亦云，需要根据实际的场景来进行处理。

分库分表的几种常见玩法及如何解决跨库查询问题

在现在的互联网架构中，分库分表是一种非常常见的手段，主要用于解决单表或者单库数据过多而导致的性能问题。

通常，我们分库有水平切分和垂直切分两种方式

垂直切分在我们的微服务架构中很常见，将数据库根据业务模块进行拆分，业务的逻辑处理都通过服务调用来进行，而不是将逻辑放在数据层面，这样就能降低数据库表与表之间的耦合度。

而水平切分，就是我们通常用来解决数据问题的手段了。将数据库中单表的数据进行切分，分成多张相同的表单，数据按照一定的规则分布到不同的数据库实例中，从而达到降低数据量、提高性能的目的。

而水平切分，就需要有分库的依据

使用哪个字段来作为分库的依据呢？

通常情况下，我们会选择主键作为分库的依据，根据一定的算法，将数据均匀的分布到每个数据库实例中，同时，尽量让请求也均匀的分布到每个数据库实例上。

例如：我们将订单表进行了切分，一分为二（DB1、BD2），订单表的主键就是订单ID，我们想要均匀的分布数据的话，我们可以对订单ID进行判断，是单数，我们就放在DB1中，是双数，我们就放到DB2中，这样，我们的数据分布就非常的平均，同时，我们的请求在概率上，也是平均的。

当然，分库依据可以很多，这个可以根据自己的业务场景进行设置，只要明白，我们分库是为了缓解数据库的压力，降低单表的数据量，如果我们分库以后，DB1的数据量和请求数远大于DB2，那么我们分库的意义就不是很大了。

而分库以后，最难解决的就是分页查询的问题

通常情况下，我们的分页查询都是通过时间维度进行排序的。如以下sql：

select*fromTorderbytimeoffsetXlimitY;

但是，分库以后，不同的数据库如何进行查询排序呢？我们就来说一跨库的分页查询方式。

全局视野方式

假设，我们现在要查询某张表的第三页数据，每页100条数据，曾经没有分库的时候，我们只需要

select*fromTorderbytimeoffset200limit100;

但是，分库以后，这第三页的100条数据就有很多种分布方式了。

1）均匀分布（极端情况）

数据非常均匀的分布在两个库中，想要找到第三页的数据，就在两个库中各取50%就好了。

2）全部来自一个库（极端情况）

数据非常不平均的分配到了一个库中，所有的数据都来至于一个库，也就是说，只需要取这个单库的数据就可以了。

3）散乱分布（通常情况）

这种情况下，我们很难知道，第三页的数据应该在不同的库中从第几条开始取数，因为分库后，我们丢失了全局视野。因此，如果我们想要精准的找到目标数据，就必须重新构建全局的视野。

如何重新构建这种全局视野呢？

还是用我们要查询第三页的数据来举例，我们可以将两个库中的第一到第三页的数据全部查询出来，然后在内存中合并后进行排序，再取出第三页的数据。

我们的sql也就发生了变化，从

select*fromTorderbytimeoffset200limit100;

改为

select*fromTorderbytimeoffset0limit100+200;

全局视野方式进行查询的好处很明显，就是能够让业务数据绝对精准的返回。但是缺点也是明显，数据的查询量大，而且消耗的内存资源较多，当页码增大的时候，性能会集聚的下降。

如果想要解决全局视野方式的缺点，我们可以做出交互上的一点小牺牲来实现

禁止跳转页方式

相信这个分页方式大家都不陌生，但是，这种分页方式确实让我们分库以后的查询难度几何级的提升，如果想要解决跨页查询的问题，我们可以对我们的分页控件进行优化，只保留“上一下”、“下一页”的功能，去掉跳转页的功能。

当禁止跳页以后，我们每次查询后，就能够得到当页最后一次查询结果的时间，我们要查询一个分页中的记录时，是需要查询大于当前时间的100条记录就可以了。

两个数据库中各取100条，然后再汇总排序，这样就能够大大的提升查询的效率，同时也保证了数据的精准。

我们的sql也就改成了

select*fromTorderbytimewheretime>@preMaxTimelimit100;

使用此方式，我们就不会因为页码增加而出现性能的下降了，只是用户的交互体验会稍差一些了。当然，如果是APP用户，就不用担心这点了，因为APP用户很少使用跳转页的交互方式。

允许精度损失方式

允许精度损失的方式就比较暴力，我们不去管数据的分布问题，只是单纯的每个库中取出50条数据，然后排序展示。

在业务中，可能会出现第二页的部分数据时间上早于第一页的数据，这主要还是根据我们的保存数据时候分分布情况来决定。如果我们存储数据的时候，分布得越平均，这种查询方式得到的结果自然就越精准。

使用这种方式，我们就不需要考虑性能上的问题，也不需要考虑页面跳转和页码的问题，查询的复杂度是最低的，是比较推荐的一种查询方式。

当然，如果你的业务不允许这样的情况出现，还需要满足交互、效率等等各种需求，那么，就只有使用最后一个方式了。

二次查询方式

这可以说是解决分库查询的究极武器了，能够保证数据的精准度、查询的效率、用户的交互页面，牺牲的只是小小的性能开销和一些代码难度的上升。

方式其实也不难，假设我们要查询第21页的数据，每页5条。这个时候，我们先假设数据是平均分布的，但是我们在每个库都查询全量的5条数据。也就是：

select*fromTorderbytimeoffset100limit5;

这时，我们得到的数据可能是这样的。

而两个DB中，最小的时间是1487500001【minTime】，这个时间记录下来。两个DB中各自的最大时间也记录下来，分别是DB1：1487500041【maxTime1】和DB2：1487500061【maxTime2】。

这时，我们在使用时间去两个数据库中再次进行查询。

select*fromTwheretimebetweenminTimeandmaxTime1orderbytime;select*fromTwheretimebetweenminTimeandmaxTime2orderbytime;

由于之前minTime来自于DB1，因此，DB1的数据不会发生变化，但是DB2中的条件被放宽了，因此可能会查询出更多的数据。结果可能如下：

而两个结果集合并以后，相当于就获得了全局视野，也就可以很容易的找出这一页需要的5条数据了。

如果谁还有更好的分库分页查询的方法，也欢迎指教！

分库分表思路与解决方案

分库分表是一种常见的数据库架构设计，它可以将一个大的数据库拆分成多个小的数据库，每个小的数据库都有自己的表和数据。这样做的好处是可以提高系统的性能和可扩展性。

分库分表的思路和解决方案有很多种，其中一种是使用中间件来实现。常用的中间件有MyCAT、ShardingSphere等。另外，还有一种基于垂直切分的方案，即按照业务模块将数据分散到不同的数据库中。

关于当数据库扼住系统性能咽喉，直接分库分表能解决吗，不建议分库分表的介绍到此结束，希望对大家有所帮助。