一、数据库瓶颈 1、IO瓶颈 2、CPU瓶颈 二、分库分表 1、水平分库 2、水平分表 3、垂直分库 4、垂直分表 三、分库分表工具 四、分库分表步骤 五、分库分表问题 1、非partition key的查询问题（水平分库分表，拆分策略为常用的hash法） 2、非partition key跨库跨表分页查询问题（水平分库分表，拆分策略为常用的hash法） 3、扩容问题（水平分库分表，拆分策略为常用的hash法） 六、分库分表总结 七、分库分表示例
不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。
1、非partition key的查询问题（水平分库分表，拆分策略为常用的hash法）
如果业务量剧增，数据库可能会出现性能瓶颈，这时候我们就需要考虑拆分数据库。从这几方面来看：
分片策略（如果要看各个策略的实际操作，看ShardingSphere专题视频即可）
在传统的中小公司里面，尤其是以企业内部的办公系统、REP系统，或者体量不是很大的互联网公司里面，搭建一套单库和单表足以应对生产的业务数据量了。而在一些互联网大公司里面，单表每天有上100w的数据业务增量时，就要考虑分库分表的策略了。否则，无论是数据的存储、访问、更新等操作，单库和单表都会影响系统和数据库的性能。
不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。
Sharding-JDBC是一个开源的适用于微服务的分布式数据访问基础类库，它始终以云原生的基础开发套件为目标。
：http://blog.csdn.net/xlgen157387/article/details/51331244
数据库在业务体系不大的情况，一般都是单库出现，通过增加主从复制提高SLA。但当业务体量不断扩大，就需要考虑进行数据拆分来解决性能瓶颈问题。
在考虑分库分表之前，我们先来探讨下分库分表是解决什么问题的一类技术。从大的方向上看，分库分表是解决两类问题：一是资源承载问题，二是开发架构问题。
面试官：这边有个数据库-单表1千万数据，未来1年还会增长多500万，性能比较慢，说下你的优化思路
昨天我们分享了怎么不停机进行分库分表数据迁移（数据库分库分表后，我们生产环境怎么实现不停机数据迁移）后来有好多朋友问我，说他们的系统虽然也到了差不多分表的地步了，但是，不知道具体拆分多少张表，分多了又怕浪费公司资源，分少了又怕后面怎么去扩容，还有另一些朋友说，所在的公司规模还不大，尚在发展中，公司压根就没这么资源给他们这么去拆分。
大家好，我是田螺。我们去面试的时候，几乎都会被问到分库分表。田螺哥整理了分库分表的15道经典面试题，大家看完肯定会有帮助的。
第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。
大中型项目，一旦数据量比较大，就要进行对数据的拆分了，一般有两种，垂直拆分与水平拆分。
前面我们讲解了数据库的读写分离方案（数据库读写分离方案，实现高性能数据库集群）来解决我们的大量读流量对系统的冲击。那随着运营部门的同事在不停的做出各种促销或者拉新活动，我们注册用户越来越多，同时订单量以及用户行为数据等持续的增加，导致我们的系统现在出现了下面这些问题。
不管是 IO 瓶颈，还是 CPU 瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。
作者：尜尜人物 cnblogs.com/littlecharacter/p/9342129.html
首先要清楚，分库和分表是两回事，是两个独立的概念。分库和分表都是为了防止数据库服务因为同一时间的访问量（增删查改）过大导致宕机而设计的一种应对策略。
在很多小型应用中都没真正使用分库分表，但是说起来并不陌生，因为我们在面试中经常会被问到，今天我们从从以下几个方面来聊聊分库分表：「是什么？解决什么？怎么做？为什么要这么做？即：」
场景：对于大型的互联网应用来说，数据库单表的记录行数可能达到千万级甚至是亿级，并且数据库面临着极高的并发访问。采用Master-Slave复制模式的MySQL架构，
单库瓶颈：如果在项目中使用的都是单MySQL服务器，则会随着互联网及移动互联网的发展，应用系统的数据量也是成指数式增长，若采用单数据库进行存储，存在一下性能瓶颈：
首先我们要知道分库、分表都是干啥的，本文主角还是我们的MySQL为第一视角。首先从字面意思来看：
昨天我们讲解了数据库分库分表后我们怎么去生成主键唯一ID（数据库分库分表后，我们怎么保证ID全局唯一），到目前为止我们已经掌握分库分表的策略了也会搭建统一发号器进行生成唯一ID。
互联网当下的数据库拆分过程基本遵循的顺序是：垂直拆分、读写分离、分库分表(水平拆分)。每个拆分过程都能解决业务上的一些问题，但同时也面临了一些挑战。
导读：本文详细介绍了中间件，主要从数据库拆分过程及挑战、主流数据库中间件设计方案、读写分离核心要点、分库分表核心要点展开说明。
把存于一个库的数据分散到多个库中，把存于一个表的数据分散到多个表中。如果说读写分离是为了分散数据库读写操作压力，分库分表就是为了分散存储压力
- 概念：分区是在数据库内部层面将一张大表的数据分割成多个更小的部分，每个部分称为一个分区。尽管从逻辑上看仍然是一个完整的表，但在物理层面上，数据被分布在不同的物理区块上，这些区块可以位于同一台服务器的不同硬盘分区，或甚至是不同服务器上。MySQL支持多种分区类型，如范围分区、列表分区、哈希分区等。
一、分库分表类型 1、单库单表 所有数据都放在一个库，一张表。 2、单库多表 数据在一个库，单表水平切分多张表。 3、多库多表 数据库水平切分，表也水平切分。 二、分库分表查询 通过分库分表规则查找到对应的表和库的过程： 如分库分表的规则是acc_id mod 4的方式，当用户新注册了一个账号，账号id的123,我们可以通过acc_id mod 4的方式确定此账号应该保存到Acc_0003表中。当用户123登录的时候，我们通过123 mod 4后确定记录在Acc_0003中。 三、分库分表的问题 分库分表
在对诸如订单、交易、支付等实时在线业务系统的研发、维护过程中，随着业务量的快速增长，我们经常会遇到由于关系型数据库（如:MySql）单表数据量增长过大而引发的线上事故；虽然这些事故多数时候是由于不合理的慢SQL而引起的系统雪崩，但有时也会出现由于数据库热点块IO争用而引发的系统性性能下降。总之，单表数据量的无限增长总是会在这样或那样的情况下增加系统的不稳定性因素。
本文是《分库分表ShardingSphere5.x原理与实战》系列的第三篇文章，本文将为您介绍 ShardingSphere 的一些基础特性和架构组成，以及在 Springboot 环境下通过 JAVA编码 和 Yml配置 两种方式快速实现分库分表。
之前有不少刚入坑 Java 的粉丝留言，想系统的学习一下分库分表相关技术，可我一直没下定决心搞，眼下赶上公司项目在使用 sharding-jdbc 对现有 MySQL 架构做分库分表的改造，所以借此机会出一系分库分表落地实践的文章，也算是自己对架构学习的一个总结。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
