数据库基础以及 MySQL 知识点

文章目录

    • 1、基本概念
    • 2、主键和外键的区别
      • 2.1、使用外键的优劣
    • 3、数据库范式
    • 4、drop、delete 与 truncate 区别?
    • 5、MySQL
      • 1、基础概念
      • 2、存储引擎
      • 2.1、InnoDB 和 MyISAM 区别
      • 2.2、InnoDB如何保持事务的四大特性(实现事务的原理)
      • 3、锁机制与 InnoDB锁算法
        • 3.1、表级锁和行级锁对比
      • 4、事务
        • 4.1、ACID 特性
        • 4.2、并发事务带来的问题
        • 4.3、事务隔离级别

1、基本概念

数据库 : 数据库(DataBase 简称 DB)就是信息的集合或者说数据库是由数据库管理系统管理的数据的集合。

数据库管理系统 : 数据库管理系统(Database Management System 简称 DBMS)是一种操纵和管理数据库的大型软件,通常用于建立、使用和维护数据库。

数据库系统 : 数据库系统(Data Base System,简称 DBS)通常由软件、数据库和数据管理员(DBA)组成。

数据库管理员 : 数据库管理员(Database Administrator, 简称 DBA)负责全面管理和控制数据库系统

元组 : 元组(tuple)是关系数据库中的基本概念,关系是一张表,表中的每行(即数据库中的每条记录)就是一个元组,每列就是一个属性。 在二维表里,元组也称为行。

:码就是能唯一标识实体的属性,对应表中的列。

候选码 : 若关系中的某一属性或属性组的值能唯一的标识一个元组,而其任何、子集都不能再标识,则称该属性组为候选码。例如:在学生实体中,“学号”是能唯一的区分学生实体的,同时又假设“姓名”、“班级”的属性组合足以区分学生实体,那么{学号}和{姓名,班级}都是候选码。

主码 : 主码也叫主键。主码是从候选码中选出来的。 一个实体集中只能有一个主码,但可以有多个候选码。

外码 : 外码也叫外键。如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码。

主属性 : 候选码中出现过的属性称为主属性。比如关系 工人(工号,身份证号,姓名,性别,部门). 显然工号和身份证号都能够唯一标示这个关系,所以都是候选码。工号、身份证号这两个属性就是主属性。如果主码是一个属性组,那么属性组中的属性都是主属性。

非主属性: 不包含在任何一个候选码中的属性称为非主属性。比如在关系——学生(学号,姓名,年龄,性别,班级)中,主码是“学号”,那么其他的“姓名”、“年龄”、“性别”、“班级”就都可以称为非主属性。

函数依赖(functional dependency) :若在一张表中,在属性(或属性组)X 的值确定的情况下,必定能确定属性 Y 的值,那么就可以说 Y 函数依赖于 X,写作 X → Y

部分函数依赖(partial functional dependency) :如果 X→Y,并且存在 X 的一个真子集 X0,使得 X0→Y,则称 Y 对 X 部分函数依赖。比如学生基本信息表 R 中(学号,身份证号,姓名)当然学号属性取值是唯一的,在 R 关系中,(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号)

完全函数依赖(Full functional dependency) :在一个关系中,若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。比如学生基本信息表 R(学号,班级,姓名)假设不同的班级学号有相同的,班级内学号不能相同,在 R 关系中,(学号,班级)->(姓名),但是(学号)->(姓名)不成立,(班级)->(姓名)不成立,所以姓名完全函数依赖与(学号,班级)

传递函数依赖 : 在关系模式 R(U)中,设 X,Y,Z 是 U 的不同的属性子集,如果 X 确定 Y、Y 确定 Z,且有 X 不包含 Y,Y 不确定 X,(X∪Y)∩Z=空集合,则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z 子集往往同属于某一个事物,因此可将其合并放到一个表中。比如在关系 R(学号 , 姓名, 系名,系主任)中,学号 → 系名,系名 → 系主任,所以存在非主属性系主任对于学号的传递函数依赖

2、主键和外键的区别

主键(主码) :主键用于唯一标识一个元组,不能有重复,不允许为空。一个表只能有一个主键

外键(外码) :外键用来和其他表建立联系用,外键是另一表的主键,外键是可以有重复的,可以是空值。一个表可以有多个外键

2.1、使用外键的优劣

优势:

  • 保证了数据库数据的一致性和完整性;
  • 级联操作方便,减轻了程序代码量;

劣势:

  • 增加了复杂性:
    • a. 每次做DELETE 或者UPDATE都必须考虑外键约束,会导致开发的时候很痛苦, 测试数据极为不方便;
    • b. 外键的主从关系是定的,假如那天需求有变化,数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦
  • 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况;
  • 对分库分表不友好 :因为分库分表下外键是无法生效的

即在系统并发量不高、不涉及分库分表的时候,还是可以使用外键来减轻一些工作量

3、数据库范式

1NF

  • 1NF是对属性的原子性,属性(对应于表中的字段)不能再被分割,也就是这个字段只能是一个值,不能再分为多个其他的字段了。1NF 是所有关系型数据库的最基本要求 ,也就是说关系型数据库中创建的表一定满足第一范式
  • 如学生(学号,姓名,性别,出生年月日),如果认为最后一列还可以再分成(出生年,出生月,出生日),它就不是一范式了,否则就是;

2NF

  • 2NF 在 1NF 的基础之上,消除了非主属性对于码的部分函数依赖,2NF是对记录的唯一性,要求记录有唯一标识,即实体的唯一性,即不存在部分依赖
  • 如表:学号、课程号、姓名、学分; 由(学号,课程号)-> 学分,而 学号->学分,课程号->学分,所以学分部分函数依赖于(学号,课程号)
  • 可能会存在问题:
    • 数据冗余:,每条记录都含有相同信息;
    • 删除异常:删除所有学生成绩,就把课程信息全删除了;
    • 插入异常:学生未选课,无法记录进数据库;
    • 更新异常:调整课程学分,所有行都调整。
  • 正确做法:
    学生:Student(学号, 姓名);
    课程:Course(课程号, 学分);
    选课关系:StudentCourse(学号, 课程号, 成绩)。

3NF

  • 3NF 在 2NF 的基础之上,消除了非主属性对于码的传递函数依赖 ,3NF是对字段的冗余性,要求任何字段不能由其他字段派生出来,它要求字段没有冗余,即不存在传递依赖

  • 如表: 学号, 姓名, 年龄, 学院名称, 学院电话,存在依赖传递: (学号) → (学生)→(所在学院) → (学院电话)

    • 可能会存在问题:

      • 数据冗余:有重复值;
      • 更新异常:有重复的冗余信息,修改时需要同时修改多条记录,否则会出现数据不一致的情况
    • 正确做法:

      学生:(学号, 姓名, 年龄, 所在学院);

      学院:(学院, 电话)。

4、drop、delete 与 truncate 区别?

  • drop(丢弃数据): drop table 表名 ,直接将表都删除掉,在删除表的时候使用
  • truncate (清空数据) : truncate table 表名 ,只删除表中的数据,再插入数据的时候自增长 id 又从 1 开始,在清空表中数据的时候使用
  • delete(删除数据) : delete from 表名 where 列名=值,删除某一列的数据,如果不加 where 子句和truncate table 表名作用类似

5、MySQL

1、基础概念

MySQL 是一种关系型数据库,主要用于持久化存储系统中的一些数据比如用户信息。

MySQL 的默认端口号是 3306

2、存储引擎

目前 mysql 默认的存储引擎是 InnoDB

2.1、InnoDB 和 MyISAM 区别

  • MyISAM 只有表级锁(table-level locking),而 InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁
  • MyISAM 不提供事务支持。InnoDB 提供事务支持,具有提交(commit)和回滚(rollback)事务的能力
  • MyISAM 不支持外键,而 InnoDB 支持
  • 数据库异常崩溃后,InnoDB 支持安全恢复,MyISAM不支持
    • 使用 InnoDB 的数据库在异常崩溃后,数据库重新启动的时候会保证数据库恢复到崩溃前的状态。这个恢复的过程依赖于 redo log

2.2、InnoDB如何保持事务的四大特性(实现事务的原理)

  • MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性,使用 undo log(回滚日志) 来保证事务的原子性
  • MySQL InnoDB 引擎通过 锁机制MVCC 等手段来保证事务的隔离性( 默认支持的隔离级别 REPEATABLE-READ
  • 保证了事务的持久性、原子性、隔离性之后,一致性才能得到保障

3、锁机制与 InnoDB锁算法

3.1、表级锁和行级锁对比
  • 表级锁: MySQL 中锁定 粒度最大 的一种锁,对当前操作的整张表加锁,实现简单,资源消耗也比较少,加锁快,不会出现死锁。其锁定粒度最大,触发锁冲突的概率最高,并发度最低,MyISAM 和 InnoDB 引擎都支持表级锁。
  • 行级锁: MySQL 中锁定 粒度最小 的一种锁,只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小,并发度高,但加锁的开销也最大,加锁慢,会出现死锁。

InnoDB 存储引擎的锁的算法有三种:

  • Record lock:记录锁,单个行记录上的锁
  • Gap lock:间隙锁,锁定一个范围,不包括记录本身
  • Next-key lock: record+gap 临键锁,锁定一个范围,包含记录本身

4、事务

事务是逻辑上的一组操作,要么都执行,要么都不执行

数据库事务可以保证多个对数据库的操作(也就是 SQL 语句)构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库操作遵循:要么全部执行成功,要么全部不执行

4.1、ACID 特性

原子性Atomicity): 事务是最小的执行单位,不允许分割。事务的原子性确保动作要么全部完成,要么完全不起作用;

一致性Consistency): 执行事务前后,数据保持一致,例如转账业务中,无论事务是否成功,转账者和收款人的总额应该是不变的;

隔离性Isolation): 并发访问数据库时,一个用户的事务不被其他事务所干扰,各并发事务之间数据库是独立的;

持久性Durability): 一个事务被提交之后。它对数据库中数据的改变是持久的,即使数据库发生故障也不应该对其有任何影响。

4.2、并发事务带来的问题

脏读(Dirty read): 当一个事务正在访问数据并且对数据进行了修改,而这种修改还没有提交到数据库中,这时另外一个事务也访问了这个数据,然后使用了这个数据。因为这个数据是还没有提交的数据,那么另外一个事务读到的这个数据是“脏数据”,依据“脏数据”所做的操作可能是不正确的。

丢失修改(Lost to modify): 指在一个事务读取一个数据时,另外一个事务也访问了该数据,那么在第一个事务中修改了这个数据后,第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失,因此称为丢失修改。 例如:事务 1 读取某表中的数据 A=20,事务 2 也读取 A=20,事务 1 修改 A=A-1,事务 2 也修改 A=A-1,最终结果 A=19,事务 1 的修改被丢失。

不可重复读(Unrepeatable read): 指在一个事务内多次读同一数据。在这个事务还没有结束时,另一个事务也访问该数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况,因此称为不可重复读。

幻读(Phantom read): 幻读与不可重复读类似。它发生在一个事务(T1)读取了几行数据,接着另一个并发事务(T2)插入了一些数据时。在随后的查询中,第一个事务(T1)就会发现多了一些原本不存在的记录,就好像发生了幻觉一样,所以称为幻读。

4.3、事务隔离级别
  • READ-UNCOMMITTED(读取未提交): 最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读

  • READ-COMMITTED(读取已提交): 允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生

  • REPEATABLE-READ(可重复读): 对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,可以阻止脏读和不可重复读,但幻读仍有可能发生。(mysql InnoDB 默认隔离级别)

  • SERIALIZABLE(可串行化): 最高的隔离级别,完全服从 ACID 的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读

    InnoDB 存储引擎在 分布式事务 的情况下一般会用到 SERIALIZABLE(可串行化) 隔离级别

你可能感兴趣的:(计算机基础,数据库,mysql)