MySQL事务管理及视图
1.MySQL事务管理
1.1什么是事务
事务是由一组 DML 语句组成的不可分割的逻辑单元。 在并发场景下，CURD 操作如果不加以控制，会出现超卖、一票多卖等数据不一致问题，这类似于多线程不加锁访问临界区资源导致的并发安全问题。 事务的核心价值是简化应用层编程模型，让开发者无需手动处理底层的异常、回滚与并发冲突。事务是为上层应用服务的，在 MySQL 中，只有 InnoDB 存储引擎支持事务。
1.2事务的操作方式
事务一般有两种提交方式：1.自动提交、2.手动提交。在命令行模式中单条sql语句其实就是一个事务，因为默认情况下MySQL的提交方式是自动提交的，也可以设置为手动提交，通过set autocommit=0设置为禁止自动提交，为1则表示设置为自动提交。设置完成后再次执行单sql语句就不再是一个事务了，而是要等到你提交或者回滚后才算做一个完整的事务。
1.3事务的隔离级别
为了保证执行事务的时候尽可能不受干扰，就有了事务的隔离性。根据不同的隔离程度，又有了不同的隔离级别。MySQL 的隔离级别有：
- 读未提交
- 读已提交
- 可重复读
- 串行化
读未提交（Read Uncommitted）： 隔离性最低，所有事务可以看到其他事务未提交的数据，相当于没有隔离。会产生脏读、不可重复读、幻读所有问题。读已提交（Read Committed）： 大多数数据库（如 Oracle、PostgreSQL）的默认隔离级别。 一个事务只能看到其他事务已经提交的数据。 解决了脏读，但会出现不可重复读、幻读。可重复读（Repeatable Read）：MySQL InnoDB 默认隔离级别。 确保同一个事务执行过程中，多次读取结果一致。 解决了脏读、不可重复读。 在普通快照读下完全不会出现幻读； 只有在当前读（UPDATE/DELETE/SELECT FOR UPDATE）时，才可能出现幻行。 MySQL 通过间隙锁 + 临键锁（Next-Key Lock）基本解决了幻读问题。串行化（Serializable）： 最高隔离级别，强制事务串行执行，完全避免所有并发问题。 但性能极低，生产环境几乎不用。
1.4隔离级别的查询
在MySQL 5.0 ~ 5.6可以使用select @@global.tx_isolation;来查询全局隔离级别。通过select @@session.tx_isolation;来查询当前会话的隔离级别。在之后的版本就需要通过select @@transaction_isolation;来查询当前会话的隔离级别.
1.5数据库的并发
数据库的并发情况一共有三种：1.读-读：不存在任何问题，不需要并发控制。2.读-写：有线程安全问题，可能遇到脏读、幻读、不可重复读等问题。3.写-写：有线程安全问题，可能会存在跟新数据丢失问题。
1.5.1读-写
多版本并发控制（MVCC）是用来解决读 - 写冲突的无锁并发控制机制。在 InnoDB 存储引擎中，每一行数据都会默认存在三个隐藏字段：
- DB_TRX_ID：6 字节，记录最后一次对该行执行插入 / 修改操作的事务 ID。
- DB_ROLL_PTR：7 字节，回滚指针，指向 undo log 中的上一个历史版本，用于构建版本链。
- DB_ROW_ID：6 字节，隐含的自增 ID（隐藏主键）。如果数据表没有显式主键，InnoDB 会使用该字段自动生成聚簇索引。
当我们执行 DML 语句修改一行数据时，原始数据不会被覆盖删除，而是会作为历史版本写入undo log。 新数据的DB_ROLL_PTR回滚指针会指向 undo log 中的旧版本，形成版本链。 如果执行回滚操作，InnoDB 会通过DB_ROLL_PTR找到历史版本，恢复数据。
这些历史版本数据不会永久保留，当没有任何事务需要访问该版本时，后台的purge 线程会自动清理无用的 undo log 日志。 undo log 是 InnoDB 专门用于存储数据历史版本的日志文件，是实现 MVCC 和事务回滚的核心。
1.6Read View
Read View 是 InnoDB 内部定义的结构体，核心作用是实现数据版本的可见性判定，仅在执行快照读时创建该对象。ReadView 包含四个核心字段，用于记录快照生成瞬间的事务状态：
- m_ids：集合类型，存储 ReadView 创建时刻，系统内所有处于 ** 活跃状态（已开启但未提交）** 的事务 ID。
- up_limit_id：低水位标识，取值为
m_ids集合中最小的事务 ID。 - low_limit_id：高水位标识，取值为 ReadView 创建时，系统即将分配的下一个事务 ID，等价于当前全局最大事务 ID 加一。
- creator_trx_id：标识创建当前 ReadView 的所属事务 ID。
事务执行快照读时，会逐行遍历数据的版本链，将数据版本的DB_TRX_ID（修改该版本的事务 ID）与 ReadView 字段做比对，完整判定逻辑如下：
- 若
DB_TRX_ID等于creator_trx_id，代表该数据版本由当前事务自身修改，版本可见；若DB_TRX_ID小于up_limit_id，代表修改该版本的事务在 ReadView 生成前已完成提交，版本可见。 - 若
DB_TRX_ID大于或等于low_limit_id，代表修改该版本的事务在 ReadView 创建之后才开启，版本不可见。 - 若上述条件均不成立，则检查
DB_TRX_ID是否存在于m_ids活跃事务集合中：若存在，说明对应事务未提交，版本不可见；若不存在，说明对应事务已提交，版本可见。
1.7RR与RC的本质区别
RR 和 RC 的核心区别，完全在于 ReadView 的生成时机不同：
RR（可重复读）事务中第一次执行快照读（普通 SELECT）时创建 ReadView， 后续整个事务生命周期内所有快照读都复用同一个 ReadView，不再新建。 因此事务全程看到的都是同一份事务快照，无法看到其他事务已提交的数据，实现可重复读。
RC（读已提交）事务中每一次执行快照读（普通 SELECT）都会重新创建新的 ReadView。 每次创建都会重新采集当前最新的活跃事务列表， 导致
m_ids、up_limit_id、low_limit_id全部实时更新。 因此每次查询都能看到其他事务最新提交的数据，实现读已提交。
2.视图
2.1视图的基本使用
创建视图：create view 视图名 as select语句;创建视图的作用是将一些需要高频查询或者修改的部分，创建为一个类似子表的结构。视图的修改会影响原表，原表的修改也会影响视图。删除视图：drop view 视图名;
2.2视图的规则与限制
同一数据库内，视图与表、其他视图名称必须唯一，不允许出现重名。 数据库对视图创建数量没有强制限制，但若将复杂查询封装为视图，尤其多层嵌套使用时，会对查询性能造成负面影响。 视图不支持建立索引，也无法绑定触发器与设置字段默认值。 借助视图可以提升数据访问的安全性，用户使用视图前需要拥有对应的访问权限。视图定义语句中可以使用 ORDER BY 子句，倘若查询视图的 SELECT 语句中也包含 ORDER BY，视图内部的排序规则会被外层排序覆盖。 视图在使用场景中可以和物理表配合进行关联、联合等查询操作。