- 事务控制语言
事务提交：commit
事务回滚：rollback
事务对应的英文单词：transaction
关闭自动提交机制:start transaction
事务（重点！！！）
事务: 就是批量的DML 语句同时成功，或者同时失败!
一个事务是一个完整的业务逻辑单元，不可再分。
和事务相关的语句只有：
DML 语句。（insert delete update ）
为什么？因为它们这三个语句都是和数据库表当中的" 数据" 相关的。
事务的存在是为了保证数据的完整性，安全性。
假设所有的业务都能使用1 条DML 语句搞定，还需要事务机制吗？
不需要事务。
但实际情况不是这样的，通常一个" 事儿（事务【业务】）" 需要多条DML 语句共同联合完成。
事务是怎么做到多条DM语句同时成功和同时失败的呢?
InnoDB存储引擎:提供一组用来记录事务性活动的日志文件
事务开启了:
insert
insert
insert
delete
update
update
update
事务结束了!
在事务的执行过程中，
每一条DML的操作都会记录到"事务性活动的日志文件"中。
在事务的执行过程中，我们可以提交事务，也可以回滚事务。
提交事务?
清空事务性活动的日志文件，将数据全部彻底持久化到数据库表中
提交事务标志着，事务的结束。并且是一种全部成功的结束。
回滚事务?
将之前所有的DM操作全部撤销，并且清空事务性活动的日志文件
回滚事务标志着，事务的结束。并且是一种全部失败的结束。
在mysql 当中默认的事务行为是怎样的?
mysq1 默认情况下是支持自动提交事务的。( 自动提交）
什么是自动提交?
每执行一条DMM 语句，则提交一次!
这种自动提交实际上是不符合我们的开发习惯，因为一个业务通常是需要多条DML 语句共同执行才能完成的，为了保证数据的安全，
必须要求同时成功之后再提交，所以不能执行一条就提交一条。
事务包括4个特性?
A: 原子性
说明事务是最小的工作单元。不可再分。
C: 一致性
所有事务要求，在同一个事务当中，所有操作必须同时成功，或者同时失败，以保证数据的一致性。
I: 隔离性
A事务和B事务之间具有一定的隔离。
教室A和教室B之间有一道墙，这道墙就是隔离性。
A事务在操作一张表的时候，另一个事务B也操作这张表会哪样?? ?
关于事务之间的隔离性
事务隔离性存在隔离级别，理论上隔离级别包括4个：
第一级别：**读未提交（**read uncommitted ）
还没提交就能读到数据。
对方事务还没有提交，我们当前事务可以读取到对方未提交的数据。
读未提交存在脏读（Dirty Read）现象：表示读到了脏的数据。
没提交就能读到更改的数据！
第二级别：**读已提交（**read committed ）
对方事务提交之后的数据我方可以读取到。
这种隔离级别解决了: 脏读现象没有了。
读已提交存在的问题是：不可重复读。
不可重复读：
提交之后才可以读到。
在事务开启之后，第一次读到的数据是3条，当前事务还没有结束，可能第二次再读取的时候，读到的数据是4条，3不等于4，称为不可重复读取。
第三级别：**可重复读（**repeatable read ）
读已提交：
提交之后也读不到，永远读取的都是刚开启事务时的数据。
只要事务不结束，读到的数据还是那样！！！
事务A开启之后，不管是多久，每一次在事务A中读取到的数据都是一致的。即使事务B将数据已经修改，并且提交了，事务A读取到的数据还是没有发生改变，这就是可重复读。
这种隔离级别解决了：不可重复读问题。
这种隔离级别存在的问题是：读取到的数据是幻象，不够真实。
例子：银行总账执行需要一些时间，期间若进行存取款业务并不影响事务。
1 点---3 点总账，3 点结束时的总账是一点中的结果！！！
要想读到B 改变之后的，需要结束A 事务后，重新开启A事务再读
第四级别：序列化读**/** 串行化读（serializable ）
每次读取到的数据都是最真实的，解决了所有问题。
效率低。需要事务排队，不能并发。
例子：类似于快照，我执行完了你才可以执行。
oracle 数据库默认的隔离级别是：读已提交。
mysql 数据库默认的隔离级别是：可重复读。
事务A一提交，事务B才能完成指令
D: 持久性
事务最终结束的一个保障。事务提交，就相当于将没有保存到硬盘上的数据保存到硬盘上!