mysql 高级篇（学习版）

一、字符集：

1、查看字符集

show variables  like '%char%';

2、修改已创建数据库的字符集

alter database db1 character set 'utf8';

3、修改已创建数据库表

alter table t1 convert to character set 'utf8';

二、mysql8.0的存储引擎

1、innodb将表结构和数据都存储在.ibd文件下

可以使用该命令查看表结构：
ibd2sdi --dump-file=demo.txt demo.ibd

2、MYISAM 的数据和索引是分开存储的

三、用户与权限管理

--创建用户并给只读权限

create USER 'gpt_read'@'%' IDENTIFIED BY 'gpt_read20240321';
GRANT SELECT ON `konneoa-system`.gpt_key TO 'gpt_read'@'%';

---用户---

1、创建用户

create user 'user'@'%' identified by 'password';

2、修改用户

update user set user = 'user' where user  = 'user';
修改完后，需执行以下命令，方可生效
flush privileges;

3、删除用户

drop user 'username'@'[host]'; 
例如： drop user 'lisi'@'localhost',不加的话，默认删除的是host为'%'的用户

4、修改当前用户密码

alter user user() identified by 'new_password';

5、修改其他用户密码

alter user 'test'@'%' identified by 'new_password';

6、设置用户密码过期时间

create user 'test'@'%' password expire interval 3 day;

----权限操作----

1、赋予权限

grant select,insert,update,delete on table.* to 'gzuser'@'%';

2、赋予所有权限

grant all privileges on *.* to 'gzuser'@'%';

注：若需要当前用户有将自己权限赋予他人的权限，需在后边添加with grant option;

3、权限查看

1）查看当前用户权限

 show grants

2）查看其他用户权限

show grants for 'user'@'主机地址';

4、收回权限

revoke select on table.* from 'gzuser'@'%';

---角色---

1、创建角色

create role 'role_name'@'host_name'; 

2、给角色赋予权限

grant (all privileges)/具体权限 on table_name to 'role_name'[@'host_name']

3、查看角色权限

show grants for 'role_name'@'host_name';

4、权限回收

revoke update(具体权限) on table.* from 'role_name';

5、查看用户角色是否激活

select current_role(); 显示为none，则没有激活权限

6、权限赋予用户

set default role 'role_name'@'host_name' to 'user'@'host_name';  授权后需退出授权用户

7、全局激活，所有角色激活

set global activate_all_roles_on_login = on;

8、撤销用户角色

revoke 'role_name'@'host_name'  from 'user'@'host_name';

9、强制角色

1)配置文件设置

[mysqld]
mandatory_roles='role_name@host_name';

2)运行时设置

set persist mandatory_roles='role_name@host_name'; #系统重启后仍然生效
set global mandatory_roles='role_name@host_name'; #系统重启后失效

四、mysql架构

1、架构层次：

1）、连接层
2）、服务层：sql接口、解析器、查询优化器、查询缓存组件（8.0已去除）
3）、存储引擎层：负责数据的存储和提取

2、查看mysql执行细节

1、查询状态：show variables like 'profiling';
2、临时修改：set profiling = 1;
3、查看最近执行的语句：show profiles; /show profile for query need_query_id；
4、查询缓存是否开启：show variables like '%query_cache_type';(缓存在8.0已去除)

3、缓冲池

1）innodb：
innodb_buffer_pool_size：是总缓冲池的大小，不会缓冲池的数量而发生变化,该值小于1GB时，设置实例无效，默认1个
innodb_buffer_pool_instances(缓冲池实例)
2）myisam: key_buffer_size;

4、引擎

innodb

优点：
1）默认引擎：支持外键事务，分布式事务
2）支持行级锁
3）服务器崩溃后，可以自动恢复，是因为支持事务的原因
4）支持聚簇索引，myisam不支持
缺点：
1）索引即数据，是因为它的数据和索引是存储在一个文件中的，耗费内存
2）写入性能没有myisam高

myisam

优点：
1）访问速度快，以insert和select为主的应用
2）针对数据统计，有对应的常数进行统计，所以count(*)的效率比较快，而innodb是累加得出总数的
缺点：
1）不支持事务，行级锁，外键，即服务器崩溃后无法修复

5、索引

---聚簇索引---

聚筷索引与非聚族索引的原理不同，在使用上也有一些区别

1、聚筷索引的叶子节点存储的就是我们的数据记录，非聚族索引的叶子节点存储的是数据位置。非聚族素引不会影响数据表的物理存储顺序。
2、一个表只能有一个聚族素引，因为只能有一种排序存储的方式，但可以有 多个非聚族素引，也就是多个索引 目录提供数据检索。 使用聚筷索引的时候，数据的 查询效率商，但如果对数据进行插入，删除，更新等操作，效率会比非聚筷索引低。

---MylSAM与InnoDB索引区别---

MyISAM的索引1方式都是“非聚簇”的，与InnoDB包含1个聚族索引是不同的。小结两种引擎中素引的区别：

1）、在InnoDB存储引擎中，我们只需要根据主键值对聚簇索引进行一次查找就能找到对应的记录，而在MyISAM中却需要进行一次回表操作，意味着MyISAM中建立的索引相当于全部都是二级索引
2）、InnoDB的数据文件本身就是索引文件，而MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。
3）、innoDB的非聚簇索引ldata域存储相应记录主键的值，而MyISAM索引记录的是地址。换句话说，InnoDB的所有非聚族素引都引用主键作为data域。
4）、MyISAM的回表操作是十分快速的，因为是拿着地址偏移量直接到文件中取数据的，反观InnoDB是通过获取主键之后再去聚簇索引里找记录，虽然说也不慢，但还是比不上直接用地址去访问。
5）、innoDB要求表必须要有主键（myisam可以没有），如果没有显式指定，则mysql系统会自动选择一个可以非空并且唯一标识数据记录的列作为主键，如果不存在这种列，则mysql自动为innodb表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整型。

---索引代价---

空间上的代价：

每建立一个索引都要为它建立一棵B+树，每一棵B+树的每一个节点都是一个数据页，一个页默认会占用16KB的存储空间，一棵很大的B+树由许多数据页组成，那就是很大的一片存储空间。

时间上的代价：

每次对表中的数据进行增、期、改操作时，都需要去修改各个B+树索引。而旦我们讲过，B+树每层节点都是 按照索引列的值 从小到大的顺序排序而组成了双向链表。不论是叶子节点中的记录，还是内节点中的记录（也就是不论是用户记录还是目录项记录）都是按照索引列的值从小到大的顺序而形成了一个单向链表。而增、 删、改操作可能会对节点和记录的排序造成破坏，所以存储引擎需要额外的时间进行一些 记录移位， 页面分裂、 页面回收 等操作来维护好节点和记录的排序。如果我们建了许多索引，每个索引对应的B+树都要进行相关的维护操作，会给性能拖后腿。

---hash结构效率快，为什么索引结构要设计成树型呢？---

1）hash索引仅能满足(=),(<>)和(in)查询，如果进行范围查询，哈希型的索引，时间复杂度会退化为O(n),而树型的“有序”特性，依然能够保持O(log2N)的高效率
2）hash索引还有一个缺陷，数据的存储是没有顺序的，在order by的情况下，使用hash索引还需要对数据进行重新排序
3）对于联合索引的情况，hash值是将联合索引键合并后一起来计算的，无法对单独的一个键或者几个索引键进行查询
4）对于等值查询来说，通常hash索引的效率并更高，不过也存在一种情况，就是索引列的重复值如果很多，效率就会降低。这是因为遇到hash冲突时，需要遍历桶中的行指针来进行比较，找到查询的关键字，非常耗时，所以，hash索引通常不会用到重复值多的列上，比如列为性别，年龄等

注：innodb没有使用hash索引，但它使用了自适应hash索引，会将一定查询次数的值的地址存储到hash表中，提高查询效率，该配置默认是开启的：show variables like '%adaptive_hash_index%';

6、MySQL8.0索引的新特性

1）、降序索引：MySQL8.0支持
2）、隐藏索引：隐藏的索引除了不能让优化器使用，其余与正常索引样

修改索引为隐藏
alter table table_name alter index index_name invisible;
修改索引为可见
alter table table_name alter index index_name visible;

7、哪些情况适合创建索引

1）字段的值有唯一性的限制
2）频繁作为where条件查询的值
3）经常group by和order by的字段
4）update、delete的where条件列
5）distinct字段
6）多表join时，关联字段加索引，并且关联字段的类型必须一致
7）使用列的类型小的创建索引（节省空间，创建的btree更利于查询）
8）使用字符串前缀创建索引，使用公式计算需要创建字符串索引的长度,该索引无法进行排序

公式：count(distinct left(列名，创建的索引长度) )/count(*)
例如：select count(distinct left(address，12)/count(*) from shop;

9）区分度高（散列性高）的列适合作为索引

使用公式计算：
select count(distinct a)/count(*) from shop

越接近1越好，大于33%就算是比较高效的索引了

10)使用最频繁的列放在联合索引的左侧，最左前缀原则

11）在多个字段都要创建索引的情况下，联合索引优于单值索引

注：限制索引数目：单表不要超过6个索引

1）占用过多的磁盘空间
2）索引会影响insert、update、delete等语句的性能，表中的数据发生变化时，维护索引会消耗资源
3）优化器在选择如何优化查询时，对每一个可能用到的索引都进行评估，从而生成最好的执行计划，索引过多，会增加MySQL优化器生成执行计划时间，降低查询性能

8、那些情况不适合建索引

1）在where条件中使用不到的字段
2）数据量小的表不要建立索引
3）有大量重复数据的列上不要创建索引
4）避免对经常更新的表创建过多的索引
5）不建议用无序的值作为索引
6）不要定义冗余或重复的索引

9、性能分析工具的使用

1）查看系统性能参数

SHOW [GLOBAL |SESSION] STATUS LIKE参数：一些常用的性能参数如下：
Connections：连接MySQL服务器的次数。
Uptime： MysQL服务器的上线时间。
Slow_queries：慢查询的次数,默认阈值是10s。
Innodb_rowsread ： select查询返回的行数
Innodb_rowsinserted ：执行INSERT操作插入的行数
Innodb_rows_updated： 执行UPDATE操作更新的行数
Innodb_rows_deleted：执行DELETE操作删除的行数
Com_select：查询操作的次数。
com_insert：插入操作的次数。对于批量插入的INSERT 操作，只累加一次。
Com_update：更新操作的次数。
com_delete：删除操作的次数。

2)统计sql的查询成本

show status like 'last_query_cost';

3)查看mysql慢日志（默认是不开启的）

1）查看慢日志查询是否开启与打开

show variables like '%slow_query_log';
set global slow_quety_log = on;

2)慢查询日志阈值查看与设置

show variables like '%long_query_time';
set global long_query_time = 1;

4)explain查看msql语句的查询顺序以及索引使用情况

5)explain展示的形式：

explain默认展示，json展示，tree展示以及官网提供的mysql woekbench
例如：explain format=json select * fromtable

6)sys schema 视图

1. 查询冗余索引

   SELECT * FROM sys.schema_redundant_indexes;

2．查询末使用过的索引

SELECT * FROM Sys.schema_unused_indexes;

3.查询索引的使用情况

SELECT index_name, rows_ selected, rows_ inserted, rows updated, rows deleted FROM sys.schema_index_statistics WHERE table_schema='dbname'

4.查询表的访问量

SELECT table_schema, table_name, SUM (io_read_requests+io+write_requests) AS io FROM sys.schema_table_statistics GROUP BY table_schema, table_name ORDER BY io DESC;

5．查询占用bufferpool较多的表

SELECT object_schema, object_name, allocated, DATA FROM sys.innodb_buffer_stats_b_table ORDER BY allocated LIMIT 10;

6.查看表的全表扫描情况

SELECT * FROM sys.statements with full table scans WHERE db='dbname';

7.监控sql执行的频率

SELECT db, exec_count, QUERY FROM sys.statement_analysis ORDER BY exec_count DESC; 

8.监控使用了排序的SQL

SELECT db, exec_count, first_seen, last_seen, QUERY FROM sys.statements_with_sorting LIMIT 1;

9.监控使用了临时表或者磁盘临时表的SQL

SELECT db, exec_count, tmp_tables, tmp_disk_tables, QUERY EROM sys. Statement_analysis WHERE, tmp_tables>0 OR tmp_disk_tables>0 ORDER BY (tmp_tables+tmp_disk_tables) DESC;

10.查看是否有行锁的情况

select * from sys.innodb_lock_waits;

注：不要在生产环境中频繁操作sys下的表，否则会影响业务查询

10、索引失效案例

1、对索引字段进行函数，以及类型转换会导致索引失效
2、范围条件右边的列索引失效
3、!=或<>的情况会失效
4、is null可以使用索引，is not null 索引失效
5、or前后存在非索引的列，索引失效
6、like 以通配符%开头的索引失效

11、关联查询优化

1、小的结果集驱动打的结果集（小的度量单位是指表行数*每行大小）
2、join语句原理：
简单嵌套循环连接，
索引嵌套循环连接（8.0.20已去除，新增hash join），
块嵌套循环连接，设置块嵌套优化：

查询状态,查看block_nested_loop是否开启：
show variables like '%optimizer_switch%';
修改join_buffer_size大小：
show variables like '%join_buffer%'; 默认为256k

12、子查询优化

尽量将子查询sql编写成外连接查询，这样的话能够用到索引

13、排序优化

1、给where条件以及排序字段添加联合索引，并做到索引覆盖（查询的字段在复合索引中）
2、排序时使用limit，查询字段不管多少，回表查询的行数少，消耗的资源少
3、order by的顺序有问题时会导致索引失效

双路排序和单路排序

双路排序：需要查询两次，第一次为查询排序字段，第二次为根据第一次排好序的数据查询其余字段，io次数多，消耗内存少
单路排序：一次性获取到所有列，将其加载到内存中，进行排序，消耗内存

优化策略：

1、尝试提高sort_buffer_size,mysql5.7该值默认为1mb

2、尝试提高max_length_for_sort_data,该值会增加用改进算法的概率，默认为1024字节（1024-8192之间调整）

3、order by时只查询query的字段，原因是查询的字段大小总和小于max_length_for_sort_data，使用单路排序，否则使用多路排序

14、覆盖索引

查询的字段在索引中，不用回表操作，便能获取到值，例如：
where条件为%开头的模糊查询和!=的查询，本应该该条件查询索引会失效，但是只要查询的字段和条件查询的字段建立了联合索引，mysql查询优化器计算消耗的成本后，则会使其索引不失效，是因为用该索引，不用回表操作

覆盖索引利弊：

--利--：

1、避免innodb二次回表操作

2、使随机io变成顺序io

--弊--：会使得索引冗余

15、索引下推

默认是开启的，在explain查询语句中的extra中显示为：using index condition

关闭：set optimizer_switch='index_condition_push_down=on'; 

ICP的使用条件

1、如果表访问的类型为range、ref、eq_ref和ref_or_null可以使用ICP
2、ICP可以用于 InnoDB 和MyISAM 表，包括分区表 InnoDB 和 MyISAM 表
3、对于 InnoDB表，ICP仅用于二级素引，ICP的目标是减少全行读取次数，从而减少IO操作。
4、当SQL使用覆盖索引时，不支持ICP。因为这种情况下使用 ICP 不会减少IO。
5.相关子查询的条件不能使用ICP

16、其他查询和优化

16.1 exist和in区别

a表小，b表大：

select * from a where exist (select cc from b where a.cc=b.cc)

a表大，b表小

select * from a where a.cc in (select cc from b)

16.2 mysql条件下count(1) 和count(*)

1、myisam引擎中，基于表锁，它维护了一个row_count,会通过row_count 来获取
2、innodb中，若使用count(1)或者count(*),mysql会自动使用key_len小的二级索引来进行统计，如果要使用count(colum)来进行统计，那么尽量使用二级索引

16.3 select *

1、mysql会在解析sql的时候将*解析为表的所有字段，该操作会浪费资源和时间
2、不能够使用覆盖索引

16.4 limit

1、当使用全表扫描的时候，使用limit，会加快查询速度
2、如果对于唯一索引进行查询，不会全表扫描，则不需要添加limit

16.5多使用COMMIT

只要有可能，在程序中尽量多使用COMMIT，这样程序的性能得到提高，需求也会因为COMMIT 所释放的资源而减少
COMMIT 所释放的资源：
1、回滚段上用于恢复数据的信息
2、被程序语句获得的锁 ，
3、redo / undo log buffer 中的空间
4、管理上述3种资源中的内部花费

16.6 uuid

由于uuid是无序的，是低中高位的顺序，可以将其调整为高中低位的顺序，使用uuid_to_bin(uuid(),true)便可调整生成的uuid为有序的
uuid_to_bin:压缩生成的uuid
bin_to_uuid:解压已有的uuid

16.7 碎片

检查表空间碎片：show table status from db_name
清理空间：OPTIMIZE TABLE table_name
ALTER TABLE table_name ENGINE= INNODB（myisam优于innodb）

17、数据库的设计规范

第一范式：确保数据表中每个字段的值必须具有原子性，也就是说数据表中每个字段的值为不可再拆分的最小数据单元
第二范式：满足第一范式的基础上，还要满足数据表里的每一条数据记录都是可唯一标识的。而且所有非主键字段，都必须完全依赖主键，不能 只依赖主键的一部分。
第三范式：要求数据表中的所有非主键字段不能依赖于其他非主键字段

18、ER模型（百度了解以及范式）

19、数据库其他调优策略

五、数据库事务

1、事务的acid

1)、原子性（atomicity）
事务的最小单元，全部成功或全部失败
2)、一致性（consistency）
从一个合法的状态到另一个合法的状态，比如转账不能为负值。
3)、隔离性（ioslation）
事务的隔离性是指一个事务的执行不能被其他事务所干扰，即一个事务内的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰
4)、持久性
指一个事务一旦被提交，它对数据库的改变是 持久性的

2、事务的状态

1）活动的
事务对应的数据库操作正在执行过程中，称为活动的
2）部分提交的
当事务汇总最后的一个操作执行完成，由于操作都在内存中执行，所造成的影响并没有刷新到磁盘中，称为部分提交的
3）失败的
当事务在活动的和部分提交的状态时发生错误时的状态
4）中止的
由于事务执行过程中出现了回滚，则该事务的状态为中止的
5）提交的
当一个处在部分提交的状态的事务将修改过的数据都同步到磁盘上后，状态为提交的

3、事务的隔离级别

1）数据并发问题

1、脏写：对于两个事务A、B,如果事务A修改了另一个未提交的事务B修改过的数据，那就意味着发生了脏写
2、脏读：对于两个事务A、B,A读取了B更新的但还没有提交的的字段，之后如果B进行了回滚，那么A读取的内容就是临时缺无效的
3、不可重复读：对于两个事务A、B，A读取了一个字段，然后B更新了该字段，之后A再次读取同一个字段，值就不同了，那就以为着发生了不可重复读。
4、幻读：对于事务A、B，A从一个表中读取了一个字段后，然后B往该表插入了一些新数据，之后A再次读取同一个表，就会多出几行，那就意味着产生了幻读。

2）SQL中的隔离级别

严重程度：脏写 ＞脏读 ＞不可重复读＞幻读
1、READ UNCOMMITTED：读未提交，北在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。不能避免脏读、不可重复读、幻读。
2、READ COMMITTED：读已提交，它满足了阿窗的简单定义：一个事务只能看见已经提交事务所做的改变。这是大多数数据库系统的默认隔离级别 （但不是MysQL默认的）。可以避免脏读，但不可重复读、幻读问题仍然 存在。
3、REPEATABLE READ：可重复读，事务A在读到一条数据之后，此时事务B对该数据进行了修改并提交，那么事务A再读该数据，读到的还是原来的内容。可以避免脏读、不可重复读，但幻读问题仍然存在。这是MysQL的 默认隔离级别。
4、SERIALIZABLE：可串行化，确保事务可以从一个表中读取相同的行。在这个事务持续期间，禁止其他事务对该表执行插入、更新和删除操作。所有的并发问题都可以避免，但性能十分低下。能避免脏读、不可重复 读和幻读。

4、事务的日志

1、redo日志：

好处：

1）降低了刷盘频率、
2）占用的空间非常小。
存储表空间ID,页号，偏移量以及需要更新的值，所需的存储空间是很小的，刷盘快

特点：

1）顺序写入磁盘的（按照产生的日志顺序写入磁盘的）
2）事务执行过程中，日志不断记录

2、undo日志

1）事务回滚
2）mvcc

5、锁

1、对数据的操作类型分为：

1）读锁：又称为共享锁，英文用S表示，针对同一数据，多事务同时进行读操作，而不会互相影响，也不会互相阻塞。

读时开启共享锁：select * from table lock in share mode;
select * from table for share;(8.0新增语法)

2）写锁：又称为排他锁，英文用X表示。当前写操作没有完成前，它会阻断其他写锁和读锁，这样就能保证在给定的时间里，只有一个事务能执行写入，并防止其他用户读取正在写入的同一资源。

2、从数据操作的粒度划分（表级，页级，行级）：

1）表锁：表级别的s锁和x锁、意向锁、自增锁、原数据锁
2）行锁：记录锁、间隙锁、临键锁、插入意向锁

3、根据锁的态度分为：乐观锁，悲观锁

4、按照加锁的方式：显示锁、隐式锁

5、其他锁：全局锁、死锁

6、查看锁状态

show status like 'innodb_row_lock%'

6、多版本并发控制

1）什么是mvcc

多版本并发控制。顾名思义，MVCC是通过数据行的多个版本管理来 实现数据库的并发控制。这项技术使得在innoDb的事务隔离级别下执行一致性读操作有了保证。换言之，就是为 了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另 一个事务释放锁。
MVCC 没有正式的标准，在不同的DBMS 中 MVCC 的实现方式可能是不同的，也不是普遍使用的（大家可以参考相 关的DEMS 文档）。这里讲解InnoDB 中 MVCC 的实现机制（MySQL其它的存储引擎并不支持它)。

2、快照读和当前读

MVCC在My$QLInnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到 不加锁 ，非阻塞并发读，而这个读指的就是快照读，而非 当前读。当前读实际上是一种加锁的操作，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。

2.1 快照读

快照读又叫一致性读，读取的是快照数据。不加锁的简单的 SELECT 都属于快照读，即不加锁的非阻塞读；

2.2 当前读

当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据），读取时还要保证其他并发事务不能修改 当前记录，会对读取的记录进行加锁。加锁的 SELECT，或者对数据进行增删改都会进行当前读。比如： SELECT * FROM student LOCK IN SHARE MODE;

3.mvcc实现原理（该实现依赖于隐藏字段，undo log、read view）

3.1什么是read view？

在 MVCC 机制中，多个事务对同一个行记录进行更新会产生多个历史快照，这些历史快照保存在 UidoLog里。如 果一个事务想要查询这个行记录，需要读取哪个版本的行记录呢？这时就需要用到 ReadView了，它帮我们解决 了行的可见性问题， Readview 就是事务在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时，会生成数据库系统当前的 一个快照，InnoDB 为每个事务构造了一个数组，用来记录并维护系统当前 活跃事务 的1D（“活跃"指的就是，启动 了但还没提交）。

3.2设计思路

read view中主要包含的四个比较重要的内容:
1）creator_trx_id:创建read view的事务id（只有对表中的记录做改动时，才会生成）
2）trx_ids:表示在生成readview时当前系统中活跃的读写事务的事务id列表
3）up_limit_id:活跃的事务中最小的事务id
4）low_limit_id:表示生成read view时系统中应该分配给下一个事务的id值，low_limit_id是系统中最大的事务id。

3.3mvcc整体操作流程

了解了这些概念之后，我们来吞下当查询一条记录的时候，系統如何通过MVCC找到它：
1、首先获取事务自己的版本号，也就是事务 1D；
2、获取 Readview;
3、查询得到的数据，然后与 Readview 中的事务版本号进行比较;
4、 如果不符合 Readview 规则，就需要从 Undo Log 中获取历史快照：
5、 最后返回符合规则的数据。
如果某个版本的数据对当前事务不可见的话，那就顾着版本链找到下一个版本的数据，继续按照上边的步骤判断 可见性，依此类推，直到版本链中的最后一 一个版本。如果最后一个版本也不可见的话，那么就意味者该条记灵对 该事务完全不可见，查询结果就不包含该记录。

注：

当隔离级别为read comminted时，一个事务中的每一次select查询都会重新获取一次read view；
当隔离级别为可重复读时，一个事务中的select查询会服用之前的read view