0%

数据库基本名词和概念

[toc]

mysql服务器响应原理dc40bbcdffcfae8017e64a957a15a800a640516e#


事务ACID#

  • A是 atomicity原子性, 事务内的行为一次性执行完,要么就回退
  • C是consistency一致性 有a+b=c的限制条件,然后a变化的同时,b也必须跟着变化
  • I是isolation隔离性 事务隔离,即事务的中间执行过程,对另外一个事务不可见。
  • D是durability持久性 提交i成功后,修改不会改变,也会被记录。

不同的存储引擎支持不同的事务处理
不支持事务的话,性能会高,但是可靠性就差。

3种读问题#

  • 脏读:数据被更新了,但是还没提交, 然后另一个事务读到了更新后的数据,结果事务回滚了,导致读的数据其实是脏数据,
  • 不可重复读: 1个事务要读2次数据(注意是单条数据),结果第一次读和第二次读数据不一致了。
    换个说法:事务T1读取某一数据,事务T2读取并修改了该数据,T1为了对读取值进行检验而再次读取该数据,便得到了不同的结果。(主要是update触发)
  • 幻读: 1个事务按照某搜索条件读了2次 数据,发现2次的记录数不一致,可能多了或者少了记录(注意是多条记录的情况, 不可重复读只针对单条数据的内容变化)(主要是insert、delete触发)
    换个说法,就是你发现数据莫名奇妙多了一条:
    第一个事务对一个表中的数据进行了修改,比如这种修改涉及到表中的“全部数据行”。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入“一行新数据”。那么,以后就会发生操作第一个事务的用户发现表中还存在没有修改的数据行

4种隔离级别#

简易记法: RU\RC\RR\SE
第一个R是read, U是uncommit, C是uncommit, R是repeated, SE是顺序

  • Read Uncommited 最低隔离级别。 写的时候可以被读取。 3个读问题都无法避免。
    如果一个事务已经开始写数据,则另外一个事务则不允许同时进行写操作,但允许其他事务读此行数据
    注意,RU级别,是有写锁的,并不是什么都没做
  • Read Committed 大部分数据库的默认隔离级别。 只有在事务提交后,另一个事务才能看到同一笔数据更新后的结果。

允许其他事务继续访问该行数据,但是未提交的写事务将会禁止其他事务访问该行,会对该写锁一直保持直到到事务提交。

区别就是写的时候,未提交的事务会禁止,相当于写的过程会让读不可见。

能解决脏读, RC隔离级别保证了对读取到的记录加锁(记录锁)

  • Repeateable Read 保证同一笔数据在事务中,必须是相同的,不会让他变化。
    能避免不可重复度和脏读, “可能”避免幻读
    RR隔离级别保证对读取到的记录加锁(记录锁),同时保证对读取的范围加锁,新的满足查询条件的记录不能够插入(间隙锁)。

  • Serializable 所有事务都必须依次顺序执行。 都能解决
    所有的读操作都是当前读,读加读锁(S锁),写加写锁(X锁)。在该隔离级别下,读写冲突,因此并发性能急剧下降,在MySQL/InnoDB中不建议使用。

2486676b1dd91f04b79a37922663c2aada317781

数据库3种完整性约束#

  • 域完整性(值约束):域完整性是保证数据库字段取值的合理性
  • 实体完整性(主键约束):指关系的主关键字不能重复也不能取“空值"。
  • 参照完整性(外键约束): 主关键字与外部关键字引用的约束条件。

4种范式#

  1. 第一范式比较简单,属性不可拆分。电话号码一个字段可以分为手机号码和座机号码两个字段。
  2. 第二范式不难理解,非主属性对候选键完全依赖,不能存在部分依赖。 即主键唯一时,能确定这个非主属性值。
    候选键只有一个主属性时则一定符合第二范式。
    候选键包含多个主属性时,可能出现不符合第二范式的情况,
  3. 第三范式去除冗余,非主属性只能存在一个表中,不应该存在多个表中,要去除无意义的数据冗余。
  4. BC范式则不应存在关键字决定关键字的情况。也就是在关联关系表中,一个表有多个属性构成复合的候选键,主属性直接不应该有互相依赖。工号和身份证号是相互依赖。
  5. 第四范式,对于候选键只能存在不超过1个多值属性。要求把同一表内的多对多关系删除。

简易版:

  • 第一范式:不可拆
  • 第二范式:多个主键时,不能只用到1个主键。
  • 第三范式:非主键属性不能冗余,最好集中到一个表
  • 第四范式:不常问, 好象是1个主键只能对应一个属性值,不要多对多,到时候就说我也不太理解,很少用到吧。

存储引擎比较#

存储引擎的比较InnoDB#

这是mysql的默认事务型引擎

用于处理短期事务(不常回滚的),但本质上还是事务型的存储引擎
数据存储在tablespace中(一堆又innoDB管理的文件,我们看不懂的那种文件)
使用MVCC支持高并发,实现4个隔离级别, 有间隙锁
使用聚簇索引

MyISAM#

MYSQL5.1之前,是默认的存储引擎
不支持事务和行级锁!也就是说不支持修复!
表存在2个文件中: 数据文件和索引文件
只能针对表加锁,不能针对行
有修复操作,但是用于修复表的错误(而不是回滚这种操作)
支持全文索引
如果表导入数据后不再更新,可以用MyISAM压缩表, 而且解压开销不大。

其他引擎#

Archive: 只支持insert和select、压缩写、支持行级锁、不是事务引擎
blackhole: 会丢弃所有插入的数据,但是会记录日志。(一般用于数据备份、日志审计)
csv:把csv文件当作mysql表。不支持索引
Federated: 是访问mysql的一个代理引擎。本质还是连接mysql。默认禁用
memory引擎: 希望快速访问不存盘, 重启后丢失也无所谓,可以i用这个,类似于H2内存数据库。
用作缓存非常不错。
NDB集群引擎: 分布式mysql集群

Q: 不同场景下的存储引擎选择#

A:

  • 日志记录: 要求插入快,可使用myisam
  • 读多写少: InnoDB, 避免崩溃恢复问题。
  • 订单处理: 事务时必须的,innoDB
  • 电子公告牌:多数应用只有几个表保存数据,核心表的压力很大
  • 大数据量: 数据仓库, infobright、NDB或者hive哈哈

Q: mysql5.7和8.0的区别#

A:

  • 新增INVISIBLE和VISIBLE语法, 以支持隐藏索引的功能,用于调试
  • MySQL 8 开始,数据库的缺省编码将改为 utf8mb4
  • 支持用命令 SET PERSIST进行配置的修改,而不是登录后台修改。
  • 新增窗口函数,支持先生成一个排序的窗口表,再做rank
    4678c23a55172ed1d7db48f6a8f6765f97e66e74
  • 更安全,支持SQL角色设置和权限设置

更详细的:MySQL5.7.X用的好好的,为什么要用MySQL8.0