前言

mysql进阶视频笔记（B站）

mysql体系结构

  1. 客户端连接器 ： native C API ,JDBC,PHP….
  2. 连接层： 连接，认证
  3. 服务层： 缓存（8版本以后已经没有了），sql接口（DML,DDL,存储过程，视图，触发器..）,解析器，查询优化器
  4. 引擎层： InnoDB,MyISAM,NDB…..（缓存，索引，存储管理）
  5. 存储层： 系统磁盘–文件和日志

存储引擎

存储引擎定义：存储数据，建立索引，更新/查询数据等技术的实现方式。存储引擎是基于表的，不是基于库，所以存储类型也被称为表类型

### InnoDB

  • 介绍

InnoDB是一种兼顾高可靠性和高性能的通用存储引擎，它是MySQL5.5以后的默认引擎。

  • 特点

支持事务，行锁，外键

  • 文件

innodb引擎每张表都对应一个表空间文件（xxx.ibd）,存储表的表结构（frm,sdi以前是frm,后来8.0后用sdi）,数据和索引

参数：innodb_file_per_table变量： 打开代表一个表一个表空间，MySQL8.0是打开的

show variables like 'innodb_file_per_table';

逻辑存储结构：

  1. tablespace(.ibd文件):表空间
  2. segment：段
  3. extent： 区 大小1M 可以放64个页
  4. page： 页 索引页，数据页 大小16k 磁盘操作的最小单元
  5. row: 行 一行一行数据 包含： trx_id最后操作事务id ,roll_pointer 指针,col1 字段1,col2 字段2…….

MyISAM

  • 特点

不支持事务，外键，支持表锁，不支持行锁，访问速度快

  • 文件

xxx.sdi 存储表结构信息,xxx.MYD 存储数据,xxx.MYI 存储索引

Memory

表数据是存储在内存中的，由于硬件问题，或者断电问题影响，只能当临时表或者缓存用

  • 特点

内存存放数据，hash索引

  • 文件

xxx.sdi：存储表结构信息

存储引擎的选择

innodb: 对事务完整性要求比较高，在并发下要求数据一致性，除增查外，还有删改多

myisam: 以读写为主，很少删改，对事务完整性和并发一致性要求不高，非核心数据 比如：日志，足迹，评论（偶尔丢一两条没事） mongoDB替代

memory: 访问快，用于临时表和缓存，无法保证数据安全性 redis替代

绝大部分都是使用：Innodb

索引

索引概述：索引是帮助MySQL高效获取数据的数据结构（有序）。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

优缺点

优点：提高数据检索，降低io. 通过索引列对数据进行排序，降低排序成本，降低CPU消耗

劣势：占用磁盘空间（磁盘便宜），提高查询效率但是降低更新速度（比例低）

索引结构

  • B+Tree索引：常见索引类型，大部分引擎都支持B+Tree索引

  • Hash索引：底层数据结构是用哈希表实现的，只有精确匹配索引列的查找才有效，不支持范围查找
  • R-tree索引:间索引是MyISAM引擎的一种特殊索引类型，主要用于地理空间数据类型，通常使用较少
  • Full-text索引：全文索引是一种通过建立倒排索引，快速匹配文档的方式。类似于Lucene,Solr,Es

InnoDB:支持B+Tree索引，Full-text(5.6以后的版本)

MyISAM:B+Tree索引,R-tree索引，Full-text索引

Memory:支持B+Tree索引，Hash索引

B-Tree：多路平衡查找树

B+Tree: 所有数据会出现在叶子节点，叶子节点形成一个单向链表

Mysql中的B+Tree:MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的B+Tree,提高区间访问性能。（双向链表）

Hash索引：类似hash的原理数组加链表

  • hash索引只能用于对等比较（=，in）,不支持范围查询（between,>,<,….）
  • 无法利用索引完成排序操作
  • 查询效率高，通常只需要一次检索就可以了，效率通常要高于B+tree索引

存储引擎的支持 在MySQL中，支持hash索引的是Memory引擎，而InnoDB中具有自适应hash功能，hash索引是存储引擎根据B+Tree索引在指定条件下自动构建的。

索引分类

主键索引：针对于表中主键创建的索引，默认自动创建，只能有一个

唯一索引：避免同一表中某数据列的值重复

常规索引：快速定位特定数据

全文索引：全文索引查找的是文本中的关键词，而不是比较索引中的值

在InnoDB存储引擎中，根据索引的存储形式，又可以分为以下两种：

聚集索引：将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据 特点：必须有，而且只有一个

二级索引（辅助索引）：将数据和索引分开存储，索引结构的叶子节点关联的是对应主键 特点：可以存在多个

聚集索引选取规则：

  • 如果存在主键，主键就是聚簇索引
  • 如果不存在主键，将使用第一个唯一索引作为聚簇索引
  • 如果不存在主键，或没有合适的唯一索引，则InnoDB会自动生产一个rowid作为隐藏的聚簇索引

InnoDB数据假设：（1页16k） 一行数据大小为1K，一页可以存储16行这样的数据。InnoDB的指针占用6个字节的空间，主键即为bigint,占用字节数为8.

B+Tree的高度为2： n为key n8+(n+1)6 = 16*1024 n 约为 1170

数据量为 1171*16 = 18736 记录

B+Tree高度为3 则 1171117116 = 21939856 记录

没想到 高度为3 都有那么多记录了！！！！！！！！！！！

SQL性能分析

SQL执行频率

Mysql客户端连接成功后，通过show[session global] status 命令可以提供服务器状态信息。通过如下指令，可以查看当前数据库的INSERT,UPDATE,DELETE,SELECT 的访问频次

show global status like 'Com_______' 7个下划线 可以看到统计信息

慢查询日志

慢查询日志记录了所有执行时间超过指定参数（long_query_time,单位：秒，默认10s）的所有SQL语句的日志。Mysql的慢查询日志默认没有开启： 查看是否开启：

show variables like 'slow_query_log'

开启方法： 需要在Mysql的配置文件（/etc/my.cnf）中配置如下信息：(Linux)

开启mysql慢查询日志开关： slow_query_log = 1

设置慢日志的时间为2秒，sql语句执行时间超过2s,就视为慢查询，记录慢查询日志： long_query_time = 2

profile详情

show profiles 能够在做sql优化时帮助我们了解时间都耗费到哪里去了。通过have_profiling参数，能够看到当前MYSQL是否支持profile操作：

select @@have_profiling

默认profiling是关闭的，可以通过set语句在session/global级别开启profiling

查看是否开启 select @@profiling 0 是没开启

开启

set @@profiling = 1

执行一系列的业务sql的操作，然后通过下面指令查看执行的耗时：

查看每一条sql的耗时基本情况:
show profiles
查看指定query_id的sql语句各个阶段的耗时情况
show profile for query query_id
查看指定query_id的sql语句cpu使用情况
show profile cpu for query query_id

explain执行计划

explain或者desc命令获取Mysql如何执行select语句的信息，包括select语句执行过程中表如何连接和连接顺序。

语法：直接在select语句之前加上关键字explain/desc

explain select 字段列表 from 表名 where 条件；

执行计划各字段的含义：

id:select查询的序列号，表示查询中执行select子句或者是操作表的顺序（id相同，执行顺序从上到下；id不同，值越大，越先执行） （多表连接才有多行）

select_type:表示select的类型，常见取值有SIMPLE(简单表，即不使用表连接或子查询)，PRIMARY(主查询，即外层的查询)，UNION(UNION中的第二个或者后面的查询语句)，SUBQUERY(SELECT/WHERE之后包含了子查询)等 （不重要）

TYPE:表示连接类型,性能由好到差的连接类型为null,system,const,eq_ref,ref,range,index,all. 优化尽量向前靠 不访问表是null 系统表system 主键和唯一索引一般出现const 使用非唯一索引查询ref 尽量别all全部扫描 index指用了索引但要扫描索引树

possible_key:显示可能应用在这张表上的索引，一个或多个

key：实际用到的索引，没有用到就是null

key_len:表示索引中使用的字节数,该值为索引字段的最大可能长度，并非实际使用长度，在不损失精确性的前提下，长度越短越好。

rows:Mysql认为必须要执行查询的行数，在InnoDB引擎表中，是一个估计值，可能并不总是准确的

filtered:表示返回结果的行数占读取行数的百分比，filtered的值越大越好

索引使用

最左前缀法则： 如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左边列开始，并且不跳过索引中的列。如果跳跃某一列，索引将部分失效（后面的字段索引失效）。 key_len可以看出走到哪个字段

范围查询： 联合索引中，出现范围查询（><）,范围查询右侧的列索引失效。业务允许情况下使用>=,<=可以解决这个问题

索引列运算：不要在索引列上进行运算操作，索引将失效。

字符串类型字段使用时，不加引号，索引失效。（隐式转换）

模糊查询：如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。

or连接条件：用or分割开的条件，如果or前的条件中的列有索引，而后面的列没有索引，那么涉及的索引都不会用到。 两个都有才行

数据分布影响：如果Mysql评估使用索引比全表更慢，则不会使用索引。 比如 查全部数据和部分数据。is null 和 is not null 走不走索引也是看数据分布的（优化器）

sql提示：优化数据库的一个重要手段，简单来说，就是在sql语句中加入一些人为的提示来达到优化操作的目的。 比如一个字段涉及多个索引的时候（单列和多列）

use index ， ignore index , force index select * from user use index(idx_user_name) where name = '张三'

use是建议mysql(有可能不接受) ignore是忽略 force是强制mysql使用

覆盖索引：尽量使用覆盖索引（查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到），减少select. 主要就是回表方面的

前缀索引：当字段类型为字符串（varchar,text等）时，有时候需要索引很长的字符串，这会让索引变的很大，查询时，浪费大量的磁盘IO，影响查询效率。此时可以将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率。语法：create index idx_xxx on table_name (column(n)) n表示提取几个字符建索引。

单列和联合索引：注意回表问题，可以使用sql提示来解决。 在业务场景中，如果存在多个查询条件，考虑针对于查询字段建立索引时，建议建立联合索引，而非单列索引。

索引设计原则

1.数据量大（数据超过100万），查询比较频繁的表。

2.针对常作为查询条件where，排序order by，分组操作group by的字段建立索引

  1. 尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度高，效率高

4.字符串长或大文本，建议前缀索引

5.尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率。

6.控制索引数量，索引越多，维护索引结构越大，影响增删改效率

7.如果索引列不能存储null值，请在创建表时使用not null约束它。当优化器知道每列是否包含null值时，它可以更好地确定哪个索引最有效地用于查询。

SQL优化

插入数据

insert优化

批量插入: insert into tb_test values (1,'tom'),(3,'jerry') –一次不超过一千条

手动控制事务：统一提交

主键顺序插入

大批量插入数据：如果一次性需要插入大批量数据，使用insert语句插入性能较低，此时可以使用MYSQL数据库提供的load指令进行插入。操作如下：

# 客户端连接服务器时，加上参数 --local-infile
mysql --local-infile -u root -p 
# 设置全局参数local—infile为1，开启从本地加载文件导入数据的开关
set global local_infile = 1;
# 执行load指令将准备好的数据，加载到表结构中
load data local infile '/root/sql/log' into table 'tb_user' fields terminated by ',' lines terminated by '\n';

注意：大批量也是主键顺序插入快

主键优化

数据组织方式

在InnoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表。

页分裂

页可以为空，也可以填充一半，也可以填充100%。每个页包含2-N行数据（如果一行数据多大，会行溢出），根据主键排列。

乱序插入就会引起页分裂现象；

页合并

当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记（flaged）为删除并且它的空间变得允许被其他记录声明使用。当页中删除的记录达到MERGE_THRESHOLD(默认为页的50%)，InnoDB会开始寻找最靠近的页（前或后）看看是否可以将两个页合并以优化空间使用。

知识小贴士： MERGE_THRESHOLD:合并页的阈值，可以自己设置，在创建表或者创建索引时指定。

主键设计原则：

  • 满足业务需求的情况下，尽量降低主键的长度
  • 插入数据时，尽量选择顺序插入，选择使用AUTO_INCREMENT自增主键
  • 尽量不要使用UUID做主键或者时其他自然主键，如身份证
  • 业务操作时，避免对主键的修改

order by优化

  1. Using filesort:通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区sort buffer中完成排序操作，所有不是通过索引直接返回排序结果的排序都叫FileSort排序

2.Using index:通过有序索引顺序扫描直接返回有序数据，这种情况即为Using Index,不需要额外排序，操作效率高。

排序也要遵循最左前缀原则

创建索引时可以指定索引字段的排序方式

非覆盖索引的查询就只能是 fileSort,大数据量排序时，可以适当增大排序的缓存区大小sort_buffer_size(默认256k).

group by优化

索引

limit优化

大数据量越往后分页，耗时越长 –>通过覆盖索引加子查询优化

select * from tb_user a , (select id from tb_sku order by id limit 9000000, 10) b where a.id = b.id

count优化

单表查询计数：

MyASIM引擎把一个表的总行数存在了磁盘上，因此执行count(*)的时候会直接返回这个数据，效率高

InnoDB引擎比较麻烦些，它执行count(*)的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。

优化思路：自己计数

count的几种用法：

count()是一个聚合函数，对于返回的结果集，一行行地判断,如果count函数的参数不是NULL，累计值就加一 ，否则不加，最后返回累计值。

用法：

  • count(*) 总记录数 有官方优化，不取值，服务层累加
  • count(主键) 总记录数 遍历整表，把id提取出来，返回服务层，按行累加
  • count(字段) 非null的数据记录数 取决于字段是否非空
  • count(1) 总记录数 遍历整表，不取值，服务层对返回的每一行放一个数字1，直接按行进行累加

按照效率排序的话：count(字段) < count(主键) < count(1) < count(*) 所以尽量使用count(*)

update优化

InnoDB的行锁是针对索引加的锁，不是针对记录加的锁，并且该索引不能失效，否则会从行锁升级为表锁。（言外之意就是更新语句的where条件最好有索引，不然就是表锁，并发性能就低了）

视图

只保存了查询的sql逻辑

作用：

  • 简单：视图可以简化用户对数据的理解，也可以简化他们的操作。
  • 安全：数据库可以授权，但不能授权到数据库特定行和特定列上。通过视图用户只能查询和修改他们所见到的数据。
  • 数据独立：视图可帮助用户屏蔽真实表结构变化带来的影响。

存储过程

sql语句的封装

触发器

锁

介绍：锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（cpu,ram,i/o）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性，有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更复杂。

分类：MYSQL中的锁，按照锁的粒度分，分为以下三类：

  1. 全局锁：锁定数据库中所有表
  2. 表级锁：每次操作锁住整张表
  3. 行级锁：每次操作锁住对应行数据

全局锁

介绍：全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将被阻塞。

其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。

flush tables with read lock;    -- 加全局锁
mysqldump -h 主机IP -uroot -p1234  xx > xx.sql;     （xx是数据库名字  这句不是sql语句使用的mysqldump）
unlock tables;    -- 解锁

特点：数据库中加全局锁，是一个比较重的操作，存在以下问题：

  1. 如果在主库上备份，那么在备份期间不能执行更新，业务基本上就得停摆。
  2. 如果在从库上备份，那么在备份期间不能执行主库同步过来的二进制日志，会导致主从延迟。

在InnoDB引擎中，我们可以在备份时加上参数 –single-transaction 参数来完成不加锁的一致性数据备份。 mysqldump --single-transaction -h 主机IP -uroot -p1234 xx > xx.sql; InnoDB引擎底层其实是用的快照读来实现的

表级锁

介绍： 表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MyISAM,InnoDB,BDB等存储引擎中。

对于表级锁，主要分为以下三类：

  1. 表锁
  2. 元数据锁（meta data lock ,MDL）
  3. 意向锁

表锁

对于表锁，分为两类：

  1. 表共享读锁 read lock 大家都能读，不能写
  2. 表独占写锁 write lock 只有我可以读写，其他不行

语法：

  1. 加锁： lock tables 表名… read/write
  2. 释放锁： unlock tables / 客户端断开连接

元数据锁

MDL加锁过程是系统自动控制，无需显示使用，在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。

为了避免DML与DDL冲突，保证读写的正确性

意向锁

为了避免DML在执行时，加的行锁与表锁的冲突，在InnoDB中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减少表锁的检查。

  1. 意向共享锁：与表锁共享锁兼容，与表锁排他锁互斥
  2. 意向排他锁：与表锁共享锁，排它锁互斥，意向锁直接不会互斥

行级锁

介绍：行级锁，每次操作锁住对应的行数据，锁定粒度最小。发生锁冲突的概率最低，并发度最高。应用在InnoDB存储引擎中。

InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。对于行级锁，主要分为以下三类：

  1. 行锁(Record Lock): 锁定单个行记录锁，防止其他事务对此行进行update和delete.在RC,RR隔离级别下都支持
  2. 间隙锁（Gap Lock): 锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事务在这个间隙进行insert,产生幻读。在RR隔离级别下都支持
  3. 临键锁（Next-Key Lock）: 行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap.在RR隔离级别下支持

行锁

InnoDB实现了以下两种类型的行锁 ：

  1. 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁。
  2. 排他锁（X）: 允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁。

默认情况下，InnoDB在REPEATABLE READ事务隔离级别运行，InnoDB使用next-key锁进行搜索和索引扫描，防止幻读。

  1. 针对唯一索引进行检索时，对已经存在的记录进行等值匹配时，将会自动优化为行锁。
  2. InnoDB的行锁是针对索引加的锁，不通过索引条件检索数据，那么InnoDB将对表中所有的记录加锁，此时就会升级为表锁。

InnoDB引擎

内存结构： Buffer pool,change buffer,log buffer

磁盘结构： system tablespace , file-per-table tablespace(xx.ibd),general tablespaces,undo tablespaces,temporary tablespaces,doublewrite buffer files,redo log.

后台线程

  1. master thread : 核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性，还包括脏页的刷新，合并插入缓存，undo页的回收。

  2. io thread: 在InnoDB存储引擎中大量使用了AIO来处理IO请求，这样可以极大地提高数据库的性能，而IO Thread主要负责这些IO请求回调。

  3. purge thread: 主要用于回收事务已经提交了的undo log.在事务提交之后，undo log 可能不用了，就用它来回收。

  4. page cleaner thread: 协助master thread 刷新脏页到磁盘的线程，它可以减轻Master Thread的工作压力，减少阻塞。

事务原理

事务：事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。

特性：ACID

ACD通过 redo log和undo log 实现；

I通过 锁和MVCC实现；

redo log:

重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。

该日志文件由两部分组成：重做日志缓冲（redo log buffer)以及重做日志文件（redo log file),前者在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中，用于在刷新脏页到磁盘，发生错误时，进行数据恢复使用。

undolog:（原子性）

回滚日志：用于记录数据被修改前的信息，作用包含两个：提供回滚和MVCC（多版本并发控制）。

undo log 和 redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条相反的update记录。当执行回滚时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log,因为这些日志可能还用于MVCC.

undo log存储：undo log采用段的方式进行管理和记录，存放在前面介绍的rollback segment回滚段中，内部包含1024个undo log segment.

MVCC

基本概念：

  1. 当前读： 读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取记录进行加锁。对于我们日常的操作，如：select … lock in share mode (共享锁)，select … for update,insert ,delete (排他锁)都是一种当前读。

  2. 快照读：简单的select(不加锁)就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。
    • read committed：每次select,都生成一个快照读。
    • repeatable read: 开启事务后第一个select语句才是快照读的地方。
    • serializable:快照读会退化为当前读。
  3. MVCC 全称Multi-Version Concurrency Control,多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段，undo log日志，readView.

记录中的三隐藏字段： | 隐藏字段 | 含义 | |———|——-| |DB_TRX_ID | 最近修改事务的id,记录插入这条记录或最后一次修改该记录的事务id | |DB_ROLL_PTR| 回滚指针，指向这条记录的上一个版本，用于配合undo log,指向上一个版本 | |DB_ROW_ID | 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段 |

可以通过查看xx.ibd文件就能看到字段，需要使用 ibd2sdi xx.ibd 命令查看

undo log日志：

  • 回滚日志，在insert，update，delete的时候产生的便于数据回滚的日志。
  • 当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。而update,delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除。

undo log版本链：不同事务或相同事务对同一条记录进行修改，会导致该记录的undo log生成一条记录版本链表，链表的头部是最新的旧记录，链表的尾部是最早的旧记录。

readView:(决定读哪一个版本)
readview(读视图)是快照读SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id.
readView中包含了四个核心字段： |字段|含义| |—|—-| |m_ids|当前活跃的事务id集合| |min_trx_id|最小活跃事务id| |max_trx_id|预分配事务id,当前最大事务id+1(因为事务id是自增的)| |creator_trx_id|readView创建者的事务id|

不同的隔离级别，生成ReadView的时机不同：（决定了提取哪个版本的数据）

  • Read committed:在事务中每一次执行快照读时生成ReadView
  • Repeatable read:仅在事务中第一次执行快照读时生成readview,后续复用该readview

readview 决定了事务链对比用的trx_id值，rr下使用同一个也就决定了它事务期间读的数是一个版本的。

MVCC+锁就搞定了事务中的 I 隔离性

redo log + undo log 保证了事务中的C 一致性。

MYSQL管理

系统自带数据库介绍： | 数据库 | 含义 | | —– | —–| | mysql | 存储Mysql服务器正常运行所需要的各种信息（时区，主从，用户，权限等） | | information_schema | 提供了访问数据库元数据的各种表和视图，包含数据库，表，字段类型及访问权限等| | performance_schema | 为mysql服务器运行时状态提供了一个底层监控功能，主要用于收集数据库服务性能参数| | sys | 包含了一系列方便DBA和开发人员利用performance_schema性能数据库进行性能调优和诊断的视图|

mysqldump:用来备份数据库或不同数据库之间进行数迁移。</br> mysqlimport/source:客户端数据导入工具，用来导入mysqldump加-T参数后导出的文本文件</br>