7、存储引擎/事务/索引/视图/三范式-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_68009130/article/details/129279029

文章详细介绍了MySQL中的存储引擎，如InnoDB、MyISAM和MEMORY，强调了它们的特性和使用场景。接着，讨论了事务的四大特性（原子性、一致性、隔离性、持久性）以及提交、回滚操作。此外，还涉及了事务的不同隔离级别及其影响。最后，提到了索引的重要性和创建规则，并简单提及视图和数据库设计的三范式。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1、存储引擎

了解内容
1.1、存储引擎是一个表存储/组织数据的方式
1.2、给表指定/添加存储引擎
在创建表的末尾加上：
ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8
ENGINE来指定存储引擎
CHARSET来指定这张表的字符编码方式
1.3、查看mysql支持哪些存储引擎
show engines \G
1.4、常见的几种存储引擎

MyLSAM
管理的表具有以下特征：

使用三个文件表示每个表：
格式文件 — 存储表结构的定义（mytable.frm）
数据文件 — 存储表行的内容（mytable.MYD）
索引文件 — 存储表上索引（mytable.MYI）
索引是一本书的目录，缩小扫描范围，提高查询效率的一种机制

特点：

可被转换为压缩、只读表来节省空间
不支持事务机制，安全性低

InnoDB
这是mysql默认的存储引擎，同时也是一个重量级的存储引擎
管理的表具有以下特征：

– 每个 InnoDB 表在数据库目录中以.frm 格式文件表示
– InnoDB 表空间 tablespace 被用于存储表的内容（表空间是一个逻辑名称。表空间存储数据+索引。）
– 提供一组用来记录事务性活动的日志文件
– 用 COMMIT(提交)、SAVEPOINT 及ROLLBACK(回滚)支持事务处理
– 提供全 ACID 兼容
– 在 MySQL 服务器崩溃后提供自动恢复
– 多版本（MVCC）和行级锁定
– 支持外键及引用的完整性，包括级联删除和更新

特点：

支持事务，安全性较高
效率不是很高，并且也不能压缩，不能转换为只读，不能很好的节省存储空间

MEMORY
数据存储在内存中，且行的长度固定；
这两个特点使得 MEMORY 存储引擎非常快
特征：

– 在数据库目录内，每个表均以.frm 格式的文件表示。
– 表数据及索引被存储在内存中。（目的就是快，查询快！）
– 表级锁机制。
– 不能包含 TEXT 或 BLOB 字段。

特点：

查询效率是最高的，不需要和硬盘交互
不安全，关机之后数据消失，因为数据和索引都是在内存当中。
2、事务(transaction)

只有DML语句才会有事务这一说，其它语句和事务无关！！！
insert、delete 、update

2.1、概述

一个事务其实就是一个完整的业务逻辑，是一个最小的工作单元
本质上，一个事务就是批量的DML语句同时成功，或者同时失败
事务的四个特性：（A、C、I、D）

A：原子性
说明事务是最小的工作单元，不可再分
C：一致性
所有事务要求，在同一个事务当中，所有操作必须同时成功，或者同时失败，以保证数据的一致性
I：隔离性
A事务和B事务之间具有一定的隔离
教室A和教室B之间有一道墙，这道墙就是隔离性。
D：持久性
事务最终结束的一个保障。事务提交，就相当于将没有保存到硬盘上的数据保存到硬盘上！

2.2、提交与回滚

提交事务
清空事务性活动的日志文件，将数据全部彻底持久化到数据库表中。
提交事务标志着，事务的结束。并且是一种全部成功的结束。

commit;
start transaction;
关闭自动提交，有利于我们的开发

回滚事务
将之前所有的DML操作全部撤销，并且清空事务性活动的日志文件
回滚事务标志着，事务的结束。并且是一种全部失败的结束。

rollback;
回滚永远都是只能回滚到上一次的提交点！

2.3、事务的隔离级别

读未提交：read uncommitted
（最低的隔离级别）《没有提交就读到了》
这种隔离级别一般都是理论上的，大多数的数据库隔离级别都是二档起步！

事务A可以读取到事务B未提交的数据
这种隔离级别存在脏读现象！(Dirty Read)

读已提交：read committed
《提交之后才能读到》

事务A只能读取到事务B提交之后的数据。
这种隔离级别解决了脏读现象。
这种隔离级别存在不可重复读取数据的问题。
在事务开启之后，第一次读到的数据是3条，当前事务还没有
结束，可能第二次再读取的时候，读到的数据是4条，3不等于4
称为不可重复读取。
这种隔离级别是比较真实的数据，每一次读到的数据是绝对的真实。
oracle数据库默认的隔离级别是：read committed

可重复读：repeatable read
《提交之后也读不到，永远读取的都是刚开启事务时的数据》

事务A开启之后，不管是多久，每一次在事务A中读取到的数据都是一致的。即使事务B将数据已经修改，并且提交了，事务A读取到的数据还是没有发生改变，这就是可重复读
可重复读解决了不可重复读取数据
可重复读会出现幻影读，即每一次读取到的数据都是幻象
早晨9点开始开启了事务，只要事务不结束，到晚上9点，读到的数据还是那样！
读到的是假象。不够绝对的真实。
mysql中默认的事务隔离级别就是这个！！！！！！！！！！！

序列化/串行化：serializable
（最高的隔离级别）

这是最高隔离级别，效率最低，解决了所有的问题
这种隔离级别表示事务排队，不能并发！
synchronized，线程同步（事务同步）
每一次读取到的数据都是最真实的，并且效率是最低的。

3、索引

1、在实际中，汉语字典前面的目录是排序的，按照a b c d e f....排序，

为什么排序呢？因为只有排序了才会有区间查找这一说！（缩小扫

描范围，其实就是扫描某个区间罢了！）

2、在mysql数据库当中索引也是需要排序的，并且这个索引的排序和

TreeSet数据结构相同。TreeSet（TreeMap）底层是一个自平衡的二叉树！

3、在mysql当中索引是一个B-Tree数据结构。遵循左小右大原则存放。采用中序遍历方式遍历取数据。在mysql当中，主键上，以及unique字段上都会自动添加索引的！！
在mysql当中，索引是一个单独的对象，不同的存储引擎以不同的形式存在

在MyISAM存储引擎中，索引存储在一个.MYI文件中。
在InnoDB存储引擎中索引存储在一个逻辑名称叫做tablespace的当中。
在MEMORY存储引擎当中索引被存储在内存当中。
不管索引存储在哪里，索引在mysql当中都是一个树的形式存在。
创建索引
索引是各种数据库进行优化的重要手段，优化的时候优先考虑的因素就是索引！
create index emp_ename_index on emp(ename);
//给emp表的ename字段添加索引，起名：emp_ename_index
删除索引
drop index emp_ename_index on emp;
//将emp表上的emp_ename_index索引对象删除
查看一个SQL语句是否使用了索引进行检索
explain select * from emp where ename = 'KING';
//扫描14条记录：说明没有使用索引。type=ALL
//扫描x条记录：说明没有使用索引。x<ALL
避免索引失效4种情况：
1、索引一定要是精确匹配
select * from emp where ename like '%T';
//模糊匹配不行，不走索引
2、索引要求各字段都有索引
使用or的时候会失效，如果使用or那么要求or两边的条件字段都要有

索引，才会走索引，如果其中一边有一个字段没有索引，那么另一个

字段上的索引也不会实现。
3、复合字段索引以第一个索引字段为主
使用复合索引的时候，没有使用左侧的列查找，索引失效
create index emp_job_sal_index on emp(job,sal);
explain select * from emp where job = 'MANAGER';
//走索引
explain select * from emp where sal = 800；
//不走索引
4、索引不参与计算
在where当中索引列参加了运算，索引失效
create index emp_sal_index on emp(sal);
explain select * from emp where sal = 800;
//走索引
explain select * from emp where sal+1 = 800;
//不走索引
5、索引不参与函数运算
在where当中索引列使用了函数
explain select * from emp where lower(ename) = 'smith';
//不走索引
4、视图（相当于脚本）

view:站在不同的角度去看待同一份数据

我们可以面向视图对象进行增删改查，对视图对象的增删改查，会导致原表被操作！

（视图的特点：通过对视图的操作，会影响到原表数据。）

4.1、创建/删除视图对象

假设有一条非常复杂的SQL语句，而这条SQL语句需要在不同的位置上反复使用。

每一次使用这个sql语句的时候都需要重新编写，很长，很麻烦，怎么办？

可以把这条复杂的SQL语句以视图对象的形式新建。

在需要编写这条SQL语句的位置直接使用视图对象，可以大大简化开发。

并且利于后期的维护，因为修改的时候也只需要修改一个位置就行，只需要
修改视图对象所映射的SQL语句。
create view dept2_view as select * from dept2;
drop view dept2_view;
4.2、增删查改（CRUD）

CRUD是在公司中程序员之间沟通的术语。一般我们很少说增删改查。

一般都说CRUD。

C:Create（增）

R:Retrive（查：检索）

U:Update（改）

D:Delete（删）
面向视图查询
select * from dept2_view;
面向视图插入
insert into dept2_view(deptno,dname,loc) values(60,'SALES', 'BEIJING');
面向视图删除
delete from dept2_view;
面向视图更新
update emp_dept_view set sal = 1000 where dname = 'ACCOUNTING';
5、DBA命令

重点就是数据的导入导出，其他命令如授权、回收权限

不需要记忆，不记得看MySQL培训日志即可
5.1、新建用户
create user username identified by 'password';
说明:username——你将创建的用户名, password——该用户的登陆密码,密码可以为空,如果为空则该用户可以不需要密码登陆服务器.
例如：
create user p361 identified by '123';
//可以登录但是只可以看见一个库 information_schema
5.2、数据导入

先登录到mysql数据库服务器上
创建数据库：create database bjpowernode;
使用数据库：use bjpowernode
然后初始化数据库：source D:\bjpowernode.sql
5.3、数据导出
在windows的dos命令窗口中：
mysqldump bjpowernode>D:\bjpowernode.sql -uroot -p123456
6、数据库设计三范式

数据库表的设计依据。教你怎么进行数据库表的设计。

设计数据库表的时候，按照以上的范式进行，可以避免表中数据的

冗余，空间的浪费。

声明：三范式是面试官经常问的，所以一定要熟记在心！

6.1、第一范式：

要求任何一张表必须有主键，每一个字段原子性不可再分

6.2、第二范式：

建立在第一范式的基础之上，要求所有非主键字段完全依赖主键，不要产生部分依赖
产生部分依赖的表是典型的多对多关系

6.3、第三范式：

建立在第二范式的基础之上，要求所有非主键字段直接依赖主键，不要产生传递依赖
产生传递依赖的表是典型的一对多关系

6.4、总结表的设计
理解并背熟

一对多：
一对多，两张表，多的表加外键！
多对多：
多对多，三张表，关系表两个外键！
一对一：
一对一放到一张表中不就行了吗？为啥还要拆分表？
在实际的开发中，可能存在一张表字段太多，太庞大。这个时候要拆分表。
一对一，外键唯一！

6.5、嘱咐一句话：

数据库设计三范式是理论上的。
实践和理论有的时候有偏差。
最终的目的都是为了满足客户的需求，有的时候会拿冗余换执行速度。
因为在sql当中，表和表之间连接次数越多，效率越低。（笛卡尔积）
有的时候可能会存在冗余，但是为了减少表的连接次数，这样做也是合理的，
并且对于开发人员来说，sql语句的编写难度也会降低。
面试的时候把这句话说上：他就不会认为你是初级程序员了！