一文让你精通数据库优化方案之分库分表

分库分表概述

读写分离分散数据库读写操作压力,分库分表分散存储压力

适用场景

类似读写分离,分库分表也是确定没有其他优化空间之后才采取的优化方案。那如果业务真的发展很快岂不是很快要进行分库分表了?那为何不一开始就设计好呢?

按照架构设计的“三原则”(简单原则,合适原则,演化原则),简单分析一下:

首先,这里的“如果”事实上发生的概率比较低,做10个业务有一个业务能活下去就很不错了,更何况快速发展,和中彩票的概率差不多。如果我们每个业务上来就按照淘宝、微信的规模去做架构设计,不但会累死自己,还会害死业务。

其次,如果业务真的发展很快,后面进行分库分表也不迟。因为业务发展好,相应的资源投入就会加大,可以投入更多的人和更多的钱,那业务分库带来的代码和业务复杂问题就可以通过加人来解决,成本问题也可以通过增加资金来解决。

业务分库

业务分表概述

带来的问题:垂直分表、增加表操作的次数、水平分表

路由问题

数据库操作问题

实现方法

类似读写分离,具体实现也是“程序代码封装”和“中间件封装”,但具体实现复杂一些,因为还有要判断SQL中具体操作的表,具体操作(例如count、order by、group by等),根据具体操作做不同的处理。

最后

欢迎大家关注我新开通的公众号【风平浪静如码】,最新最全多家公司java面试题整理了1000多道400多页pdf文档,文章都会在里面更新,整理的资料也会放在里面。

喜欢文章记得关注我点个赞哟,感谢支持!

原文地址:https://blog.51cto.com/14570694/2470959

时间: 02-14

一文让你精通数据库优化方案之分库分表的相关文章

数据库架构演变及分库分表

当生产环境中业务量激增,数据库数据量也会极具增加.当数据库的数据量达到一定程度时(数据库瓶颈),数据库宿主机负载超高,会严重影响业务,严重时会导致数据库宕机.为了避免这种极端情况的发生,我们应当在发生前做好预案,用于解决数据库数据量过载的问题.以下是我个人工作中使用的解决方案:1)数据库主从或多主多从方案2)数据库冷热数据拆分3)数据库分库分表操作4)在数据库前端增加缓存redis或memcached 一开始时,公司部分业务的架构如下(全都是单节点情况)经过自己强调该架构严重的缺点:节点单一,服

【转】MYSQL数据库数据拆分之分库分表总结

http://wentao365.iteye.com/blog/1740691 数据存储演进思路一:单库单表单库单表是最常见的数据库设计,例如,有一张用户(user)表放在数据库db中,所有的用户都可以在db库中的user表中查到.数据存储演进思路二:单库多表随着用户数量的增加,user表的数据量会越来越大,当数据量达到一定程度的时候对user表的查询会渐渐的变慢,从而影响整个DB的性能.如果使用MySQL, 还有一个更严重的问题是,当需要添加一列的时候,mysql会锁表,期间所有的读写操作只能

数据库分库分表思路

一. 数据切分 关系型数据库本身比较容易成为系统瓶颈,单机存储容量.连接数.处理能力都有限.当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库.优化索引,做很多操作时性能仍下降严重.此时就要考虑对其进行切分了,切分的目的就在于减少数据库的负担,缩短查询时间. 数据库分布式核心内容无非就是数据切分(Sharding),以及切分后对数据的定位.整合.数据切分就是将数据分散存储到多个数据库中,使得单一数据库中的数据量变小,通过扩充主机的数量缓解单一数据库的性能问题,从而达到提升

【转】mysql分库分表,数据库分库分表思路

原文:https://www.cnblogs.com/butterfly100/p/9034281.html 复制过来收藏 一. 数据切分 关系型数据库本身比较容易成为系统瓶颈,单机存储容量.连接数.处理能力都有限.当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库.优化索引,做很多操作时性能仍下降严重.此时就要考虑对其进行切分了,切分的目的就在于减少数据库的负担,缩短查询时间. 数据库分布式核心内容无非就是数据切分(Sharding),以及切分后对数据的定位.整合.数据

数据库-数据库设计-分库分表

为什么要分库分表 分库分表的设计 带来的问题 扩容 分布式事务 多个路由字段怎么设置 关于分库分表最全的一篇文章 这里介绍设计分库分表框架时应该考虑的设计要点,并给出相应的解决方案. 一.整体的切分方式 简单来说,数据的切分就是通过某种特定的条件,将我们存放在同一个数据库中的数据分散存放到多个数据库(主机)中,以达到分散单台设备负载的效果,即分库分表. 数据的切分根据其切分规则的类型,可以分为如下两种切分模式. 垂直(纵向)切分:把单一的表拆分成多个表,并分散到不同的数据库(主机)上. 水平(横

【转】数据库SQL优化大总结之 百万级数据库优化方案

原帖地址:http://www.cnblogs.com/yunfeifei/p/3850440.html#undefined 1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 最好不要给数据库留NULL,尽可能的使用 NOT NULL填充数据库. 备注.描

数据库SQL优化大总结之 百万级数据库优化方案(转)

出处:http://www.cnblogs.com/yunfeifei/p/3850440.htm 网上关于SQL优化的教程很多,但是比较杂乱.近日有空整理了一下,写出来跟大家分享一下,其中有错误和不足的地方,还请大家纠正补充.这篇文章我花费了大量的时间查找资料.修改.排版,希望大家阅读之后,感觉好的话推荐给更多的人,让更多的人看到.纠正以及补充. 1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对

数据库SQL优化百万级数据库优化方案

1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: selectidfromtwherenumisnull 最好不要给数据库留NULL,尽可能的使用 NOT NULL填充数据库. 备注.描述.评论之类的可以设置为 NULL,其他的,最好不要使用NULL. 不要以为 NULL 不需要空间,比如:char(100) 型,在字段建立

(转)数据库SQL优化大总结之 百万级数据库优化方案

网上关于SQL优化的教程很多,但是比较杂乱.近日有空整理了一下,写出来跟大家分享一下,其中有错误和不足的地方,还请大家纠正补充. 这篇文章我花费了大量的时间查找资料.修改.排版,希望大家阅读之后,感觉好的话推荐给更多的人,让更多的人看到.纠正以及补充. 1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id f