MySQL 分库拆表方案

基本认识

用分库&拆表是解决数据库容量问题的唯一途径。

分库&拆表也是解决性能压力的最优选择。

分库 – 不同的数据表放到不同的数据库服务器中（也可能是虚拟服务器）

拆表 – 一张数据表拆成多张数据表，可能位于同一台服务器，也可能位于多台服务器（含虚拟服务器）。

去关联化原则

摘除数据表之间的关联，是分库的基础工作。

摘除关联的目的是，当数据表分布到不同服务器时，查询请求容易分发和处理。

学会理解反范式数据结构设计，所谓反范式，第一要点是不用外键，不允许Join操作，不允许任何需要跨越两个表的查询请求。第二要点是适度冗余减少查询请求，比如说，信息表，fromuid, touid, message字段外，还需要一个fromuname字段记录用户名，这样查询者通过touid查询后，能够立即得到发信人的用户名，而无需进行另一个数据表的查询。

去关联化处理会带来额外的考虑，比如说，某一个数据表内容的修改，对另一个数据表的影响。这一点需要在程序或其他途径去考虑。

分库方案

安全性拆分

将高安全性数据与低安全性数据分库，这样的好处第一是便于维护，第二是高安全性数据的数据库参数配置可以以安全优先，而低安全性数据的参数配置以性能优先。参见运维优化相关部分。

顺序写数据与随机读写数据分库

顺序数据与随机数据区分存储地址，保证物理i/o优化。

基于业务逻辑拆分

根据数据表的内容构成，业务逻辑拆分，便于日常维护和前端调用。

基于业务逻辑拆分，可以减少前端应用请求发送到不同数据库服务器的频次，从而减少链接开销。

基于业务逻辑拆分，可保留部分数据关联，前端web工程师可在限度范围内执行关联查询。

基于负载压力拆分

基于负载压力对数据结构拆分，便于直接将负载分担给不同的服务器。

基于负载压力拆分，可能拆分后的数据库包含不同业务类型的数据表，日常维护会有一定的烦恼。

分表方案

数据量过大或者访问压力过大的数据表需要切分

忙闲分表

单数据表字段过多，可将频繁更新的整数数据与非频繁更新的字符串数据切分

范例user表，个人简介，地址，QQ号，联系方式，头像这些字段为字符串类型，更新请求少；最后登录时间，在线时常，访问次数，信件数这些字段为整数型字段，更新频繁，可以将后面这些更新频繁的字段独立拆出一张数据表，表内容变少，索引结构变少，读写请求变快。

横向切表

等分切表，如哈希切表或其他基于对某数字取余的切表。等分切表的优点是负载很方便的分布到不同服务器；缺点是当容量继续增加时无法方便的扩容，需要重新进行数据的切分或转表。而且一些关键主键不易处理。

递增切表，比如每1kw用户开一个新表，优点是可以适应数据的自增趋势；缺点是往往新数据负载高，压力分配不平均。

日期切表，适用于日志记录式数据，优缺点等同于递增切表。

个人倾向于递增切表，具体根据应用场景决定。

热点数据分表

将数据量较大的数据表中将读写频繁的数据抽取出来，形成热点数据表。通常一个庞大数据表经常被读写的内容往往具有一定的集中性，如果这些集中数据单独处理，就会极大减少整体系统的负载。

热点数据表与旧有数据关系

可以是一张冗余表，即该表数据丢失不会妨碍使用，因源数据仍存在于旧有结构中。优点是安全性高，维护方便，缺点是写压力不能分担，仍需要同步写回原系统。

可以是非冗余表，即热点数据的内容原有结构不再保存，优点是读写效率全部优化；缺点是当热点数据发生变化时，维护量较大。

具体方案选择需要根据读写比例决定，在读频率远高于写频率情况下，优先考虑冗余表方案。

热点数据表可以用单独的优化的硬件存储，比如昂贵的闪存卡或大内存系统。

热点数据表的重要指标

热点数据的定义需要根据业务模式自行制定策略，常见策略为，按照最新的操作时间；按照内容丰富度等等。

数据规模，比如从1000万条数据，抽取出100万条热点数据。

热点命中率，比如查询10次，多少次命中在热点数据内。

理论上，数据规模越小，热点命中率越高，说明效果越好。需要根据业务自行评估。

热点数据表的动态维护

加载热点数据方案选择

定时从旧有数据结构中按照新的策略获取

在从旧有数据结构读取时动态加载到热点数据

剔除热点数据方案选择

基于特定策略，定时将热点数据中访问频次较少的数据剔除

如热点数据是冗余表，则直接删除即可，如不是冗余表，需要回写给旧有数据结构。

通常，热点数据往往是基于缓存或者key-value 方案冗余存储，所以这里提到的热点数据表，其实更多是理解思路，用到的场合可能并不多….

表结构设计

查询冗余表设计

涉及分表操作后，一些常见的索引查询可能需要跨表，带来不必要的麻烦。确认查询请求远大于写入请求时，应设置便于查询项的冗余表。

实战范例，

用户分表，将用户库分成若干数据表

基于用户名的查询和基于uid的查询都是高并发请求。

用户分表基于uid分成数据表，同时基于用户名做对应冗余表。

冗余表要点

数据一致性，简单说，同增，同删，同更新。

可以做全冗余，或者只做主键关联的冗余，比如通过用户名查询uid，再基于uid查询源表。

中间数据表

为了减少会涉及大规模影响结果集的表数据操作，比如count，sum操作。应将一些统计类数据通过中间数据表保存。

中间数据表应能通过源数据表恢复。

实战范例：

论坛板块的发帖量，回帖量，每日新增数据等

网站每日新增用户数等。

后台可以通过源数据表更新该数字。

历史数据表

历史数据表对应于热点数据表，将需求较少又不能丢弃的数据存入，仅在少数情况下被访问

MySQL 分库拆表方案相关推荐

最全的MySQL分库分表方案总结
" 面试中我们经常会碰到的关于分库分表的问题!今天就给大家介绍互联网公司常用 MySQL 分库分表方案!希望对大家的面试有所帮助! 数据库瓶颈不管是 IO 瓶颈,还是 CPU 瓶颈,最终都 ...
【mysql】MySQL 分库分表方案，总结的非常好！
文章目录 1. 数据库架构演变 2. 分库分表前的问题 3. 分库分表的方式方法 3.1 垂直分库 3.2 水平拆分水平分表水平分库分表水平分库分表切分规则 4. 分库分表后面临的问题 4.1 ...
【分库、分表】MySQL分库分表方案
一.Mysql分库分表方案 1.为什么要分表: 当一张表的数据达到几千万时,你查询一次所花的时间会变多,如果有联合查询的话,我想有可能会死在那儿了.分表的目的就在于此,减小数据库的负担,缩短查询时间. ...
MySQL第六讲 MySQL分库分表方案
分库分表概念分库分表就是业务系统将数据写请求分发到master节点,而读请求分发到slave 节点的一种方案,可以大大提高整个数据库集群的性能.但是要注意,分库分表的一整套逻辑全部是 ...
Java教程之mysql分库分表方案
1 前言各位小伙伴,在目前企业级开发中采用Mysql做为数据库是一个主流选择,而当数据量比较大的情况下,为了支撑项目的正常快速的运行,我们不得不选择对数据库分库分表操作,本章节就对数据库的分表做一些 ...
MySQL 分库分表方案，总结的非常好！
数据库分库分表前言公司最近在搞服务分离,数据切分方面的东西,因为单张包裹表的数据量实在是太大,并且还在以每天60W的量增长. 之前了解过数据库的分库分表,读过几篇博文,但就只知道个模糊概念, 而且 ...
超详细的mysql分库分表方案
我们都知道,随着业务量的增长,数据量也会随之增加,这个时候就需要关注业务大表,因为大表会影响查询性能,DDL变更时间很长,影响业务的可用性,同时导致从库延迟很大,如果业务做了读写分离,导致用户重复操作 ...
mysql 分库分表 ~ 方案选择浅谈
一简介:分库分表的理解二具体: 1 当由于单台DB业务增长导致的服务器压力时,就必须横向进行扩展 2 本文仅从中间层观点进行分析三现有方案方案1 shard ...
mysql分库分表方案浅析
分库分表(这里不讨论中间件) 分库:原因:单机负载高,优点:降低单机负载分表:原因:单表读写压力大或者数据增长快,优点:使用多个表,提高读写效率 1.(代码)分表,即把一个很大的表达数据分到几个表中 ...

MySQL 分库拆表方案

MySQL 分库拆表方案相关推荐

最新文章

热门文章