在互联网项目中，当业务规模越来越大，数据也越来越多，随之而来的就是数据库压力会越来越大。
在很多小型应用中都没真正使用分库分表，但是说起来并不陌生，因为我们在面试中经常会被问到，今天我们从从以下几个方面来聊聊分库分表：「是什么？解决什么？怎么做？为什么要这么做？即：」
我们可能会采取各种方式去优化，比如之前文章提到的缓存方案，SQL优化等等，除了这些方式以外，这里再分享几个针对数据库优化的常规手段：「数据读写分离」与「数据库Sharding」。这两点基本上是大中型互联网项目中应用的非常普遍的方案了。
分析一下问题出现在哪儿呢？ 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到 1000W 或 100G 以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。
1，更多的静态资源:将代码中的大量枚举（容器加载时写入map，放入本地缓存），数据库中的定义表（定时任务放入缓存），固定配置，HTML文件等静态化处理，缓存起来！
在并发场景中，当热点缓存Key失效时，流量瞬间打到数据库中，此所谓缓存击穿现象；当大范围的缓存Key失效时，流量也会打到数据库中，此所谓缓存雪崩现象。
前两篇文章重点讲到了Mysql数据库的主从同步和读写分离，使用主从同步实现从数据库从主数据同步数据保持主从数据一致性，读写分离使用主数据库负责写操作，多个从数据库负责读操作，由于从库可以进行拓展，所以处理更多的读请求也没问题。但是如果业务比较多，写请求越来越多要如何处理呢？可能有人说我可以再加一个master分担写操作，但是两个master数据肯定是需要同步的，主主同步 + 主从同步很显然会让我们的系统架构变得更为的复杂。所以本篇文章主要讨论一个对写操作进行切分的技术：分库分表。
随着计算机系统规模变得越来越大，将所有的业务单元集中部署在一个或若干个大型机上的体系架构，已经越来越不能满足当今计算机系统。同时，随着微型计算机的出现，越来越多廉价的PC机成为了各大企业IT架构的首选，分布式的处理方式越来越受到业界的青睐。本文将介绍分布式架构的发展历史和分布式架构的一些相关概念。
【什么是分库分表】 顾名思义，分库分表就是对数据库进行拆分以一种方式或策略。但是在实际场景中，分库和分表并不是要一起出现的。有可能只是需要分表，有可能只是需要分库，如果在大流量高并发的情况下，会出现分库分表同时出现的情况。那么什么时候需要分库分表呢？ 我们可以考虑一个问题，比如我们所负责的业务线是全新的而且非常有潜质的，那么我们设计系统的时候，通常并不会上来就做分库分表的设计，因为对于系统上线之后的发展，没有人可以预测出来。所以，都会中规中矩的按照单库单表的方式去设计。忙碌了好几个月，系统上线了，最初每天
所谓的“大表”指的是一张表中有大量的数据，而通常情况下数据量越多，那么也就意味着查询速度越慢。这是因为当数据量增多时，那么查询一个数据需要匹配和检索的内容也就越多，而检索的项目越多，那么查询速度也就越慢。
文章介绍了分布式数据库在项目中的使用场景，以及基于腾讯云DCDB的具体实现方案，包括分表、分库、负载均衡、高可用等方面的内容。
一、前言 随着社会的发展，技术的进步，以前的大型机架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了，替代它的就是当下最火的分布式架构，从大型机到分布式，经历了好几个阶段，我们弄明白各个阶段的架构，才能更好地理解和体会分布式架构的好处，那么本文我们就来聊聊分布式架构的演进过程，希望能给大家带来眼前一亮的感觉。 二、背景说明 我们都知道一个成熟的大型网站的系统架构并非一开始就设计的非常完美，也没有一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来的，慢
随着社会的发展，技术的进步，以前的大型机架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了，替代它的就是当下最火的分布式架构，从大型机到分布式，经历了好几个阶段，我们弄明白各个阶段的架构，才能更好地理解和体会分布式架构的好处，那么本文我们就来聊聊分布式架构的演进过程，希望能给大家带来眼前一亮的感觉。
随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天百万级甚至上亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。
本人转载：http://www.cnblogs.com/ejiyuan/archive/2010/10/29/1796292.html
集群 小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。
哈啰出行作为阿里系共享单车的头部企业，在江湖中的知名度还是有的，而今天我们就来看一道哈啰 Java 一面中的经典面试题：当数据表中数据量过大时，应该如何优化查询速度？
我们说 Mysql 单表适合存储的最大数据量，自然不是说能够存储的最大数据量，如果是说能够存储的最大量，那么，如果你使用自增 ID，最大就可以存储 2^32 或 2^64 条记录了，这是按自增 ID 的数据类型 int 或 bigint 来计算的；如果你不使用自增 id，且没有 id 最大值的限制，如使用足够长度的随机字符串，那么能够限制单表最大数据量的就只剩磁盘空间了。显然我们不是在讨论这个问题。
随着业务量越来越大，单台数据库服务器性能已无法满足业务需求，该考虑增加服务器扩展架构了。主要思想是分解单台数据库负载，突破磁盘I/O性能，热数据存放缓存中，降低磁盘I/O访问频率。
http://mini.eastday.com/mobile/170809003639242.html
与其直接用些抽象、晦涩的技术名词去给分布式下一个定义，还不如从理解分布式的发展驱动因素开始，我们一起去探寻它的本质，自然而然地也就清楚它的定义了。
本文根据虢国飞老师在dbaplus社群【2019年1月5日数据架构与优化沙龙上海站】现场演讲内容整理而成，点击文末【阅读原文】可下载完整PPT~
1、非partition key的查询问题（水平分库分表，拆分策略为常用的hash法）
上篇说道了数据库读写分离，对于大型网站来说这么说是十分有必要的。数据库在整个互联网架构中担当的角色无法有两个，存储和运算，很多时候这两个是并存的，但是在后期，对于上亿条数据来说，让数据库既要存储，又要运算，那么是这是不可行的，为了保证性能，我们仅仅只需要最大化利用DB的存数就行了，连数据库之间的外键管理都不需要，只要有对应的id即可。那么既然如此，相互关联的表肯定会存在删除业务，而事实上我们如今处理删除操作并不是真正的删除，只不过我们添加了is_delete这个字段来标注逻辑是否删除即可。不然在表关联的时候
随着互联网及移动互联网的发展，应用系统的数据量也是成指数式增长，若采用单数据库进行数据存储，存在以下性能瓶颈：
在无尽的代码优化中时刻提醒着自己保持克制，一定不要骂娘，一定不要让自己生气，不然受伤的只会是自己。
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。
不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。
在MySQL数据库中，表设计的优劣同样对性能有非常重要的影响。本节将介绍表设计的优化方法，包括巧用多表关系、表结构设计优化和表拆分等。
一、数据库瓶颈 1、IO瓶颈 2、CPU瓶颈 二、分库分表 1、水平分库 2、水平分表 3、垂直分库 4、垂直分表 三、分库分表工具 四、分库分表步骤 五、分库分表问题 1、非partition key的查询问题（水平分库分表，拆分策略为常用的hash法） 2、非partition key跨库跨表分页查询问题（水平分库分表，拆分策略为常用的hash法） 3、扩容问题（水平分库分表，拆分策略为常用的hash法） 六、分库分表总结 七、分库分表示例
随着社会的发展、互联网技术的进步，以前的大型机服务端架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了，替代它的就是当下最火的互联网分布式架构。 从若干年前大行其道的传统大型机到如今的分布式架构，技术发展已经经历了好几个阶段，我们只有弄明白典型互联网架构在各个阶段的演进，才能更好地理解和体会分布式架构的好处，从而有助于我们序设计适合于自已公司、产品或项目的架构（也包括设计即时通讯网专注的IM和消息推送这类系统，因为技术思路的原理都是一脉相承的）。那么本文我们就来聊聊分布式架构的演进过程，希望能给大家带来眼前一亮的感觉。
mysql高并发的解决方法有：优化SQL语句，优化数据库字段，加缓存，分区表，读写分离以及垂直拆分，解耦模块，水平切分等。
读写分离是让主库处理事务性增删改，而从库处理查操作。数据库复制来把事务性操作的数据变更同步到从库。
当数据库的数据量过大，大到一定的程度，我们就可以进行分库分表。那么基于什么原则，什么方法进行拆分，这就是本篇所要讲的。
不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。
随着社会的发展、互联网技术的进步，以前的大型机服务端架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了，替代它的就是当下最火的互联网分布式架构。
随着公司业务快速发展,数据量的猛增,数据库就会变成系统的瓶颈.随之而来的就会有运维成本高,数据热点等诸多问题.
这篇文章是对又拍网公布的数据库案例的分析总结 又拍网是一个大型照片分享社区，数据库架构也是从简单到复杂发展起来的 数据库进化过程 （1）一主一从 最初是由一台主库和一台从库组成，当时从库只用作备份和容灾，当主库出现故障时，从库就手动变成主库 随着压力的增加，加上了memcached （2）一主多从 通过添加多个从库来分流查询压力 （3）数据库拆分 随着数据量的增加，读写压力都迅速增加，决定进行数据库拆分，将数据存放到不同的数据库服务器中 数据库拆分 一般可以按两个纬度来拆分数据:
不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务服务来看就是，可用数据库连接少甚至无连接可用，那导致的问题就可以想象了吧：并发量、吞吐量、崩溃等等情况。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
