第11章 数据库的设计规范【2.索引及调优篇】【MySQL高级】3

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 第11章 数据库的设计规范【2.索引及调优篇】【MySQL高级】3

2.一个多对多的关系转换成一个数据表

这个ER模型中的多对多的关系有1个,即商品和订单之间的关系,同品类的商品可以出现在不同的订单中,不同的订单也可以包含同一类型的商品,所以它们之间的关系是多对多。针对这种情况需要设计一个独立的表来表示,这种表一般称为中间表。


我们可以设计一个独立的订单详情表,来代表商品和订单之间的包含关系。这个表关联到2个实体,分别是订单、商品。所以,表中必须要包括这2个实体转换成的表的主键。除此之外,我们还要包括该关系自有的属性:商品数量,商品下单价格以及商品名称。

#订单详情表
CREATE TABLE `order_detail`(
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '订单详情编号',
`order_id` bigint(20)DEFAULT NULL COMMENT '订单编号',
`sku_id` bigint(20) DEFAULT NULL COMMENT 'sku_id ',
`sku_name` varchar(200) DEFAULT NULL COMMENT 'sku名称',
`sku_num` varchar(200)DEFAULT NULL COMMENT '购买个数',
`create_time` datetime DEFAULT NULL COMMENT '操作时间',
PRIMARY KEY (`id`) USING BTREE
)ENGINE=InnoDB AUTO_INCRENENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='订单明细表';

3.通过外键来表达1对多的关系

在上面的表的设计中,我们可以用外键来表达1对多的关系。比如在商品评论表sku_comments中

我们分别把user_id、sku_id定义成外键,以使用下面的语句设置外键。

CONSTRAINT fk_comment_user FOREIGN KEY (user_id) REFERENCES user_info (id),
CONSTRAINT fk_comment_sku FOREIGN KEY (sku_id)REFERENCES sku_info (sku_id)

外键约束主要是在数据库层面上保证数据的一致性,但是因为插入和更新数据需要检查外键,理论上性能会有所下降,对性能是负面的影响。


实际的项目,不建议使用外键,一方面是降低开发的复杂度(有外键的话主从表类的操作必须先操作主表),另外是有外键在处理数据的时候非常麻烦。在电商平台,由于并发业务量比较大,所以一般不设置外键,以免影响数据库性能。


在应用层面做数据的一致性检查,本来就是一个正常的功能需求。如学生选课的场景,课程肯定不是输入的,而是通过下拉或查找等方式从系统中进行选取,就能够保证是合法的课程ID,因此就不需要靠数据库的外键来检查了。

4.把属性转换成表的字段

在刚刚的设计中,我们也完成了把属性都转换成了表的字段,比如把商品属性转换成了商品信息表中的字段。

CREATE TABLE `sku_info`(
  `sku_id` bigint(20) NOT NULL AUTO_INCREMENT COPMENT'商品编号(itemID)',
   `price` decimal(10,0) DEFAULT NULL COMMENT'价格',
  `sku_name` varchar(200) DEFAULT NULL COMMENT 'sku名称',
  `sku_desc` varchar(2000) DEFAULT NULL COMMENT'商品规格描述',
  `category3_id` bigint(20) DEFAULT NULL COMMENT'三级分类id(冗余)',
  `color` varchar (2000) DEFAULT NULL COMMENT '颜色',
  `is_sale` tinyint(3) NOT NULL DEFAULT '0' CONMMENT'是否销售(1:是0:否)',
  PRIMARY KEY (`id`) USING BTREE
)ENGINE=InnoDB AUTO_INCRENENT=45 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT= '商品表';

到这里,我们通过创建电商项目业务流程的ER模型,再把ER模型转换成具体的数据表的过程,完成利用ER模型设计电商项目数据库的工作。


其实,任何一个基于数据库的应用项目,都可以通过这种先建立ER 模型 ,再转换成数据表的方式,完成数据库的设计工作。创建ER模型不是目的,目的是把业务逻辑梳理清楚,设计出优秀的数据库。不是为了建模而建模,要利用创建ER模型的过程来整理思路,这样创建ER模型才有意义。


9.数据表的设计原则

综合以上内容,总结出数据表设计的一般原则:“三少一多”
1.数据表的个数越少越好

RDBMS的核心在于对实体和联系的定义,也就是E-R图(Entity Relationship Diagram),数据表越少,证明实体和联系设计得越简洁,既方便理解又方便操作。
2.数据表中的字段个数越少越好

字段个数越多,数据冗余的可能性越大。设置字段个数少的前提是各个字段相互独立,而不是某个字段的取值可以由其他字段计算出来。当然字段个数少是相对的,通常会在数据冗余检索效率中进行平衡。
3.数据表中联合主键的字段个数越少越好

设置主键是为了确定唯一性,当一个字段无法确定唯一性的时候,就需要采用联合主键的方式(也就是用多个字段来定义一个主健)。联合主键中的字段越多,占用的索列空间越大,不仅会加大理解难度,还会增加运行时间和索引空间,因此联合主键的字段个数越少越好。
4.使用主键和外键越多越好

数据库的设计实际上就是定义各种表,以及各种字段之间的关系。这些关系越多,证明这些实体之间的冗余度越低,利用度越高。这样做的好处在于不仅保证了数据表之间的独立性,还能提升相互之间的关联使用率。

外键指外键关系,不一定使用外键约束实现


“三少一多"原则的核心就是简单可复用。简单指的是用更少的表、更少的字段、更少的联合主键字段来完成数据表的设计。可复用则是通过主键、外键的使用来增强数据表之间的复用率。因为一个主键可以理解是一张表的代表。键设计得越多,证明它们之间的利用率越高。


注意:

这个原则并不是绝对的,有时候需要牺牲数据的冗余度来换取数据处理的效率

10.数据库对象编写建议

前面讲了数据库的设计规范,下面给出的这些规范适用于大多数公司,按照下面的规范来使用数据库,这样数据库可以发挥出更高的性能

10.1 关于库

1.【强制】库的名称必须控制在32个字符以内,只能使用英文字母、数字和下划线,建议以英文字母开头。

2.【强制】库名中英文一律小写 ,不同单词采用 下划线 分割。须见名知意。

3.【强制】库的名称格式:业务系统名称_子系统名。

4.【强制】库名禁止使用关键字(如type,order等)。

5.【强制】创建数据库时必须显式指定字符集 ,并且字符集只能是utf8或者utf8mb4。

6.创建数据库SQL举例:CREATE DATABASE crm_fund DEFAULT CHARACTER SET ‘utf8’ ;

7.【建议】对于程序连接数据库账号,遵循 权限最小原则。

使用数据库账号只能在一个DB下使用,不准跨库。程序使用的账号 原则上不准有drop权限 。

8.【建议】临时库以 tmp_ 为前缀,并以日期为后缀;

备份库以 bak_为前缀,并以日期为后缀。

10.2 关于表、列

1.【强制】表和列的名称必须控制在32个字符以内,表名只能使用英文字母、数字和下划线,建议以英文字母开头 。

2.【强制】表名、列名一律小写 ,不同单词采用下划线分割。须见名知意。

.3【强制】表名要求有模块名强相关,同一模块的表名尽量使用统一前缀 。比如:crm_fund_item

4.【强制】创建表时必须显式指定字符集 为utf8或utf8mb4。

5.【强制】表名、列名禁止使用关键字(如type,order等)。

6.【强制】创建表时必须 显式指定表存储引擎 类型。如无特殊需求,一律为InnoDB。

7.【强制】建表必须有comment。

8.【强制】字段命名应尽可能使用表达实际含义的英文单词或 缩写 。如:公司 ID,不要使用corporation_id, 而用corp_id 即可。

9.【强制】布尔值类型的字段命名为is_描述 。如member表上表示是否为enabled的会员的字段命名为 is_enabled。

10.【强制】禁止在数据库中存储图片、文件等大的二进制数据通常文件很大,短时间内造成数据量快速增长,数据库进行数据库读取时,通常会进行大量的随机IO操作,文件很大时,IO操作很耗时。通常存储于文件服务器,数据库只存储文件地址信息。

11.【建议】建表时关于主键: 表必须有主键

(1)强制要求主键为id,类型为int或bigint,且为auto_increment 建议使用unsigned无符号型。

(2)标识表里每一行主体的字段不要设为主键,建议设为其他字段如user_id,order_id等,并建立unique key索引。因为如果设为主键且主键值为随机插入,则会导致innodb内部页分裂和大量随机I/O,性能下降。

12.【建议】核心表(如用户表)必须有行数据的创建时间字段 (create_time)和 最后更新时间字段(update_time),便于查问题。

13.【建议】表中所有字段尽量都是 NOT NULL 属性,业务可以根据需要定义 DEFAULT值 。 因为使用NULL值会存在每一行都会占用额外存储空间、数据迁移容易出错、聚合函数计算结果偏差等问题。

14.【建议】所有存储相同数据的 列名和列类型必须一致 (一般作为关联列,如果查询时关联列类型不一致会自动进行数据类型隐式转换,会造成列上的索引失效,导致查询效率降低)。

15.【建议】中间表(或临时表)用于保留中间结果集,名称以 tmp_ 开头。备份表用于备份或抓取源表快照,名称以 bak_ 开头。中间表和备份表定期清理。

16.【示范】一个较为规范的建表语句:

CREATE TABLE user_info (
  `id` int unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `user_id` bigint(11) NOT NULL COMMENT '用户id',
  `username` varchar(45) NOT NULL COMMENT '真实姓名',
  `email` varchar(30) NOT NULL COMMENT '用户邮箱',
  `nickname` varchar(45) NOT NULL COMMENT '昵称',
  `birthday` date NOT NULL COMMENT '生日',
  `sex` tinyint(4) DEFAULT '0' COMMENT '性别',
  `short_introduce` varchar(150) DEFAULT NULL COMMENT '一句话介绍自己,最多50个汉字',
  `user_resume` varchar(300) NOT NULL COMMENT '用户提交的简历存放地址',
  `user_register_ip` int NOT NULL COMMENT '用户注册时的源ip',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  `user_review_status` tinyint NOT NULL COMMENT '用户资料审核状态,1为通过,2为审核中,3为未通过,4为还未提交审核',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_user_id` (`user_id`),
  KEY `idx_username`(`username`),
  KEY `idx_create_time_status`(`create_time`,`user_review_status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='网站用户基本信息'

17.【建议】创建表时,可以使用可视化工具。这样可以确保表、字段相关的约定都能设置上。

实际上,我们通常很少自己写 DDL 语句,可以使用一些可视化工具来创建和操作数据库和数据表。


可视化工具除了方便,还能直接帮我们将数据库的结构定义转化成 SQL 语言,方便数据库和数据表结构

的导出和导入。

10.3 关于索引

1.【强制】InnoDB表必须主键为id int/bigint auto_increment,且主键值禁止被更新 。

2.【强制】InnoDB和MyISAM存储引擎表,索引类型必须为BTREE 。

3.【建议】主键的名称以 pk_ 开头,唯一键以 uni_ 或uk_ 开头,普通索引以 idx_ 开头,一律使用小写格式,以字段的名称或缩写作为后缀。

4.【建议】多单词组成的columnname,取前几个单词首字母,加末单词组成column_name。如:sample 表 member_id 上的索引:idx_sample_mid。

5.【建议】单个表上的索引个数不能超过6个 。

6.【建议】在建立索引时,多考虑建立联合索引 ,并把区分度最高的字段放在最前面。

7.【建议】在多表 JOIN 的SQL里,保证被驱动表的连接列上有索引,这样JOIN 执行效率最高。

8.【建议】建表或加索引时,保证表里互相不存在冗余索引 。

比如:如果表里已经存在key(a,b),则key(a)为冗余索引,需要删除

10.4 SQL编写

1.【强制】程序端SELECT语句必须指定具体字段名称,禁止写成 *。

2.【建议】程序端insert语句指定具体字段名称,不要写成INSERT INTO t1 VALUES(…)。

3.【建议】除静态表或小表(100行以内),DML语句必须有WHERE条件,且使用索引查找。

4.【建议】INSERT INTO…VALUES(XX),(XX),(XX)… 这里XX的值不要超过5000个。 值过多虽然上线很快,但会引起主从同步延迟。

5.【建议】SELECT语句不要使用UNION,推荐使用UNION ALL,并且UNION子句个数限制在5个以内。

6.【建议】线上环境,多表 JOIN 不要超过5个表。

7.【建议】减少使用ORDER BY,和业务沟通能不排序就不排序,或将排序放到程序端去做。ORDER BY、GROUP BY、DISTINCT 这些语句较为耗费CPU,数据库的CPU资源是极其宝贵的。

8.【建议】包含了ORDER BY、GROUP BY、DISTINCT 这些查询的语句,WHERE 条件过滤出来的结果集请保持在1000行以内,否则SQL会很慢。

9.【建议】对单表的多次alter操作必须合并为一次

对于超过100W行的大表进行alter table,必须经过DBA审核,并在业务低峰期执行,多个alter需整合在一起。

因为alter table会产生表锁 ,期间阻塞对于该表的所有写入,对于业务可能会产生极大影响。

10.【建议】批量操作数据时,需要控制事务处理间隔时间,进行必要的sleep。

11.【建议】事务里包含SQL不超过5个。因为过长的事务会导致锁数据较久,MySQL内部缓存、连接消耗过多等问题。

12.【建议】事务里更新语句尽量基于主键或UNIQUE KEY,如UPDATE… WHERE id=XX;

否则会产生间隙锁,内部扩大锁定范围,导致系统性能下降,产生死锁。

11. PowerDesigner的使用

【MySQL数据库教程天花板,mysql安装到mysql高级,强!硬!-哔哩哔哩】
PowerDesigner是一款开发人员常用的数据库建模工具,用户利用该软件可以方便地制作 数据流程图 、概念数据模型 、 物理数据模型 ,它几乎包括了数据库模型设计的全过程,是Sybase公司为企业建模和设计提供的一套完整的集成化企业级建模解决方案


安装

PowerDesigner16.5安装及基础使用

11.1 开始界面

当前使用的PowerDesigner版本是16.5的。打开软件即是此页面,可选择Create Model,也可以选择Do Not Show page Again,自行在打开软件后创建也可以!完全看个人的喜好,在后面的学习中不在显示此页面。

“Create Model”的作用类似于普通的一个文件,该文件可以单独存放也可以归类存放。

“Create Project”的作用类似于文件夹,负责把有关联关系的文件集中归类存放。

11.2 概念数据模型

常用的模型有4种,分别是 概念模型(CDM Conceptual Data Model) , 物理模型(PDM,Physical Data Model) , 面向对象的模型(OOM Objcet Oriented Model) 和 业务模型(BPM Business Process Model) ,我们先创建概念数据模型


点击上面的ok,即可出现下图左边的概念模型1,可以自定义概念模型的名字,在概念模型中使用最多的就是如图所示的Entity(实体),Relationship(关系)


Entity实体

选中右边框中Entity这个功能,即可出现下面这个方框,需要注意的是书写name的时候,code自行补全,name可以是英文的也可以是中文的,但是code必须是英文的。

点击菜单栏中的Entity图标

左键点击到工作区域,可以多次左键创建实体,右键即可退出状态,双击实体即可编辑实体


填充实体字段

General中的name和code填好后,就可以点击Attributes(属性)来设置name(名字),code(在数据库中的字段名),Data Type(数据类型) ,length(数据类型的长度)

Name: 实体名字一般为中文,如论坛用户

Code: 实体代号,一般用英文,如XXXUser

Comment:注释,对此实体详细说明

Code属性:代号,一般用英文UID DataType

Domain域,表示属性取值范围如可以创建10个字符的地址域

M:Mandatory强制属性,表示该属性必填。不能为空

P:Primary Identifer是否是主标识符,表示实体唯一标识符

D:Displayed显示出来,默认全部勾选


Data Type可以使用点击下拉框或…的方式设置,字符串类型必须设置长度

Ctrl+D删除行或者点击

在此下图说明name和code的起名方法

设置主标识符

如果不希望系统自动生成标识符而是手动设置的话,那么切换到Identifiers选项卡,添加一行Identifier,然后单击左上角的“属性”按钮,然后弹出的标识属性设置对话框中单击“添加行”按钮,选择该标识中使用的属性。例如将学号设置为学生实体的标识。


放大模型

创建好概念数据模型如图所示,但是创建好的字体很小,读者可以按着ctrl键同时滑动鼠标的可滑动按钮即可放大缩写字体,同时也可以看到主标识符有一个*号的标志,同时也显示出来了,name,Data type和length这些可见的属性


实体关系

同理创建一个班级的实体(需要特别注意的是,点击完右边功能的按钮后需要点击鼠标指针状态的按钮或者右击鼠标即可,不然很容易乱操作,这点注意一下就可以了),然后使用Relationship(关系)这个按钮可以连接学生和班级之间的关系,发生一对多(班级对学生)或者多对一(学生对班级)的关系。

如图所示


需要注意的是点击Relationship这个按钮,就把班级和学生联系起来了,就是一条线,然后双击这条线进行编辑,在General这块起name和code


上面的name和code起好后就可以在Cardinalities这块查看班级和学生的关系,可以看到班级的一端是一条线,学生的一端是三条,代表班级对学生是一对多的关系即one对many的关系,点击应用,然后确定即可


一对多和多对一练习完还有多对多的练习,如下图操作所示,老师实体和上面介绍的一样,自己将name,data type等等修改成自己需要的即可,满足项目开发需求即可。(comment是解释说明,自己可以写相关的介绍和说明)


多对多需要注意的是自己可以手动点击按钮将关系调整称为多对多的关系many对many的关系,然后点

击应用和确定即可


综上即可完成最简单的学生,班级,教师这种概念数据模型的设计,需要考虑数据的类型和主标识码,是否为空。关系是一对一还是一对多还是多对多的关系,自己需要先规划好再设计,然后就ok了。




Ctrl+S保存学生管理系统-1.cdm

11.3 物理数据模型

上面是概念数据模型,下面介绍一下物理数据模型,以后 经常使用 的就是物理数据模型。打开PowerDesigner,然后点击File–>New Model然后选择如下图所示的物理数据模型,物理数据模型的名字自己起,然后选择自己所使用的数据库即可。


创建好主页面如图所示,但是右边的按钮和概念模型略有差别,物理模型最常用的三个是table(表) , view(视图) , reference(关系) ;


鼠标先点击右边table这个按钮然后在新建的物理模型点一下,即可新建一个表,然后双击新建如下图所示,在General的name和code填上自己需要的,点击应用即可),如下图:


然后点击Columns,如下图设置,非常简单,需要注意的就是P(primary主键) , F (foreign key外键) ,M(mandatory强制性的,代表不可为空) 这三个


在此设置学号的自增(MYSQL里面的自增是这个AUTO_INCREMENT),班级编号同理,不多赘述!


在下面的这个点上对号即可,就设置好了自增


全部完成后如下图所示。


班级物理模型同理如下图所示创建即可


完成后如下图所示


上面的设置好如上图所示,然后下面是关键的地方,点击右边按钮Reference这个按钮,因为是班级对学生是一对多的,所以鼠标从学生拉到班级如下图所示,学生表将发生变化,学生表里面增加了一行,这行是班级表的主键作为学生表的外键,将班级表和学生表联系起来。(仔细观察即可看到区别。)


做完上面的操作,就可以双击中间的一条线,显示如下图,修改name和code即可


但是需要注意的是,修改完毕后显示的结果却如下图所示,并没有办法直接像概念模型那样,修改过后显示在中间的那条线上面,自己明白即可。


学习了多对一或者一对多的关系,接下来学习多对对的关系,同理自己建好老师表,这里不在叙述,记得老师编号自增,建好如下图所示

下面是多对多关系的关键,由于物理模型多对多的关系需要一个中间表来连接,如下图,只设置一个字段,主键,自增


点击应用,然后设置Columns,只添加一个字段


这是设置字段递增,前面已经叙述过好几次


设置好后如下图所示,需要注意的是有箭头的一方是一,无箭头的一方是多,即一对多的多对一的关系

需要搞清楚,学生也可以有很多老师,老师也可以有很多学生,所以学生和老师都可以是主体;


可以看到添加关系以后学生和教师的关系表前后发生的变化


Ctrl+S保存学生管理系统-1.pdm

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
18天前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
15天前
|
存储 SQL 关系型数据库
MySQL的安装&数据库的简单操作
本文介绍了数据库的基本概念及MySQL的安装配置。首先解释了数据库、数据库管理系统和SQL的概念,接着详细描述了MySQL的安装步骤及其全局配置文件my.ini的调整方法。文章还介绍了如何启动MySQL服务,包括配置环境变量和使用命令行的方法。最后,详细说明了数据库的各种操作,如创建、选择和删除数据库的SQL语句,并提供了实际操作示例。
58 13
MySQL的安装&数据库的简单操作
|
2天前
|
关系型数据库 Unix MySQL
MySQL是一种关系型数据库管理系统
MySQL是一种关系型数据库管理系统
11 2
|
5天前
|
Oracle NoSQL 关系型数据库
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
17 2
|
10天前
|
SQL 关系型数据库 MySQL
创建包含MySQL和SQLServer数据库所有字段类型的表的方法
创建一个既包含MySQL又包含SQL Server所有字段类型的表是一个复杂的任务,需要仔细地比较和转换数据类型。通过上述方法,可以在两个数据库系统之间建立起相互兼容的数据结构,为数据迁移和同步提供便利。这一过程不仅要考虑数据类型的直接对应,还要注意特定数据类型在不同系统中的表现差异,确保数据的一致性和完整性。
22 4
|
20天前
|
存储 SQL 关系型数据库
使用MySQL Workbench进行数据库备份
【9月更文挑战第13天】以下是使用MySQL Workbench进行数据库备份的步骤:启动软件后,通过“Database”菜单中的“管理连接”选项配置并选择要备份的数据库。随后,选择“数据导出”,确认导出的数据库及格式(推荐SQL格式),设置存储路径,点击“开始导出”。完成后,可在指定路径找到备份文件,建议定期备份并存储于安全位置。
160 11
|
2月前
|
SQL 关系型数据库 MySQL
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
170 2
|
2月前
|
弹性计算 关系型数据库 数据库
手把手带你从自建 MySQL 迁移到云数据库,一步就能脱胎换骨
阿里云瑶池数据库来开课啦!自建数据库迁移至云数据库 RDS原来只要一步操作就能搞定!点击阅读原文完成实验就可获得一本日历哦~
|
2月前
|
关系型数据库 MySQL 数据库
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决
RDS MySQL灾备服务协同解决方案构建问题之数据库备份数据的云上云下迁移如何解决
|
21天前
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案

热门文章

最新文章

下一篇
无影云桌面