MySQL 分库分表

最新推荐文章于 2024-09-01 23:44:31 发布

jakeswang

最新推荐文章于 2024-09-01 23:44:31 发布

阅读量370

点赞数 1

分类专栏：数据库相关文章标签： mysql分库分表

本文链接：https://blog.csdn.net/jakeswang/article/details/103878046

版权

数据库相关专栏收录该内容

8 篇文章 0 订阅

订阅专栏

MySQL 分库分表：

https://cloud.tencent.com/developer/article/1539420

众所周知，数据库很容易成为应用系统的瓶颈。单机数据库的资源和处理能力有限，在高并发的分布式系统中，可采用分库分表突破单机局限。本文总结了分库分表的相关概念、全局ID的生成策略、分片策略、平滑扩容方案、以及流行的方案。

1 分库分表概述

在业务量不大时，单库单表即可支撑。

当数据量过大存储不下、或者并发量过大负荷不起时，就要考虑分库分表。

1.1 分库分表相关术语

读写分离: 不同的数据库，同步相同的数据，分别只负责数据的读和写；
分区: 指定分区列表达式，把记录拆分到不同的区域中(必须是同一服务器，可以是不同硬盘)，应用看来还是同一张表，没有变化；
分库：一个系统的多张数据表，存储到多个数据库实例中；
分表: 对于一张多行(记录)多列(字段)的二维数据表，又分两种情形：

(1) 垂直分表: 竖向切分，不同分表存储不同的字段，可以把不常用或者大容量、或者不同业务的字段拆分出去；

(2) 水平分表(最复杂): 横向切分，按照特定分片算法，不同分表存储不同的记录。

1.2 真的要采用分库分表？

需要注意的是，分库分表会为数据库维护和业务逻辑带来一系列复杂性和性能损耗，除非预估的业务量大到万不得已，切莫过度设计、过早优化。

规划期内的数据量和性能问题，尝试能否用下列方式解决：

当前数据量：如果没有达到几百万，通常无需分库分表；
数据量问题：增加磁盘、增加分库(不同的业务功能表，整表拆分至不同的数据库)；
性能问题：升级CPU/内存、读写分离、优化数据库系统配置、优化数据表/索引、优化 SQL、分区、数据表的垂直切分；
如果仍未能奏效，才考虑最复杂的方案：数据表的水平切分。

大公司的开源产品：2 全局ID生成策略

2.1 自动增长列

优点：数据库自带功能，有序，性能佳。

缺点：单库单表无妨，分库分表时如果没有规划，ID可能重复。解决方案：

2.1.1 设置自增偏移和步长

## 假设总共有 10 个分表
## 级别可选: SESSION(会话级), GLOBAL(全局)
SET @@SESSION.auto_increment_offset = 1; ## 起始值, 分别取值为 1~10
SET @@SESSION.auto_increment_increment = 10; ## 步长增量

如果采用该方案，在扩容时需要迁移已有数据至新的所属分片。

2.1.2 全局ID映射表

在全局 Redis 中为每张数据表创建一个 ID 的键，记录该表当前最大 ID；

每次申请 ID 时，都自增 1 并返回给应用；

Redis 要定期持久至全局数据库。

2.2 UUID(128位)

在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成UUID的API。

UUID 由4个连字号(-)将32个字节长的字符串分隔后生成的字符串，总共36个字节长。形如：550e8400-e29b-41d4-a716-446655440000。

UUID 的计算因子包括：以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。

UUID 是个标准，其实现有几种，最常用的是微软的 GUID(Globals Unique Identifiers)。

优点：简单，全球唯一；

缺点：存储和传输空间大，无序，性能欠佳。

2.3 COMB(组合)

参考资料：The Cost of GUIDs as Primary Keys

组合 GUID(10字节) 和时间(6字节)，达到有序的效果，提高索引性能。

2.4 Snowflake(雪花) 算法

参考资料：twitter/snowflake，Snowflake 算法详解

Snowflake 是 Twitter 开源的分布式 ID 生成算法，其结果为 long(64bit) 的数值。

其特性是各节点无需协调、按时间大致有序、且整个集群各节点单不重复。

该数值的默认组成如下(符号位之外的三部分允许个性化调整)：

1bit: 符号位，总是 0(为了保证数值是正数)。
41bit: 毫秒数(可用 69 年)；
10bit: 节点ID(5bit数据中心 + 5bit节点ID，支持 32 * 32 = 1024 个节点)
12bit: 流水号(每个节点每毫秒内支持 4096 个 ID，相当于 409万的 QPS，相同时间内如 ID 遇翻转，则等待至下一毫秒)

3 分片策略

3.1 连续分片

根据特定字段(比如用户ID、订单时间)的范围，值在该区间的，划分到特定节点。

水平分库分表切分规则
1. RANGE
  
  从0到10000一个表，10001到20000一个表；
2. HASH取模
  
  一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题。取用户id，然后hash取模，分配到不同的数据库上。
3. 地理区域
  
  比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。
4. 时间
  
  按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。