事务ACID特性
原子性：事务要么同时成功，要么同时失败，事务的原子性通过undo log日志保证
一致性：业务代码要抛出报错，让数据库回滚
隔离性：事务并发执行时，他们内部操作不能互相干扰
持久性：事务一旦提交，对数据库的改变就是永久性的。通过redo log日志保证
隔离性
InnoDB引擎中的隔离机制的通过MySQL的锁和MVCC机制实现，提供四种隔离级别，越高隔离性越好，分别是读未提交（脏读）、读已提交（不可重复读）、可重复读（赃写）、串行
读取未提交：所有事务都可以看到其他未提交事务的执行结果。
脏读：是某一事务A读取到了事务B修改未提交的数据。
读以提交 ：一个事务只能看见已经提交事务所做的改变。解决：解决读未提交事务A修改数据，事务B读取数据，事务B读取的数据是原始数据（不是事务A修改后的数据。
不可重复读：在一个事务内，多次读取同一个数据，却返回了不同的结果，有其他事务对这段数据进行了修改并提交。
可重读：事务读取数据只会读到访问数据第一个版本的数据。
解决：事务A多次查看数据中事务B读取数据提交，数据是最初打开事务看到的数据。
赃写：事务A查看数据永远是第一次查看的数据，事务B修改数据+500，事务A修改数据+200，就会覆盖之前修改的数据。
可重读带来的脏写的解决方案：乐观锁，在数据库中修改可重读的实现机制：通过mvvc机制，会记录当版本的数据。
可串行：事务会等待其他事务执行结束，否则会阻塞。
解决：脏读、不可重复度、赃写。
持久性
Buffer Pool内存写完了，会写redo log 日志记录在那个表修改了什么。
即便MySQL挂了，我们还可以根据redo log 对数据进行恢复。
redo log是顺序写的，写入速度很块，恢复速度也快。
MySQL的事务ACID特性有哪些？
原子性、一致性、隔离性、持久性
原子性：事务要么同时成功，要么同时失败，事务的原子性通过undo log日志保证
一致性：业务代码要抛出报错，让数据库回滚
隔离性：事务并发执行时，他们内部操作不能互相干扰
持久性：事务一旦提交，对数据库的改变就是永久性的。通过redo log日志保证
InnoDB引擎中的隔离机制有哪些？
读未提交、读已提交、可重读、串行化
InnoDB引擎中的隔离机制是如何实现的？
InnoDB引擎中的隔离机制的通过MySQL的锁和MVCC机制实现
读未提交是什么？带来什么问题？
读未提交是事务可以读取到其他事务修改还未提交的数据。
会带脏读的问题，读取到其他事务修改未提交的数据，然后其他事务回滚，就会导致读取的数据和数据库不一致。
读以提交是什么？解决什么问题？带来什么问题？
读已提交只能读到其他事务已提交的数据。
可能会带来不重复读问题，读取几次间隔，其他多个事务修改提交。
可重读是什么？解决什么问题？带来什么问题？
可重读是多次读取数据只能读到数据第一个版本。
解决了读已提交带来的不可重读问题。
可能带来赃写问题，多个事务回去数据修改，会覆盖之前的修改结果。
可重读可以用乐观锁等方式解决。
可串行是什么？解决什么问题？带来什么问题？
隔离机制可穿行是事务操作数据会等到其他事务操作完成，
解决了脏读，不可重读，赃写问题，但是在高并发的时候会影响性能。
查询数据需要使用事务吗？
如果是可重读事务隔离性，保证所有数据的都是同时性。
对并发性比较高使用读以提交隔离级别。
传统公司使用读以提交隔离级别
为什么要写先到redo日志中？
redo日志是一个文件是按照磁盘顺序写的，速度快。
磁盘文件idb是多个文件在磁盘的不同位置，实现不了磁盘顺序写。
三大范式
事务与锁
事务ACID特性
原子性：事务要么同时成功，要么同时失败，事务的原子性通过undo log日志保证
一致性：业务代码要抛出报错，让数据库回滚
隔离性：事务并发执行时，他们内部操作不能互相干扰
持久性：事务一旦提交，对数据库的改变就是永久性的。通过redo log日志保证
原子性
一致性
隔离性
InnoDB引擎中的隔离机制的通过MySQL的锁和MVCC机制实现，提供四种隔离级别，越高隔离性越好。
读未提交：脏读
读已提交：不可重复读
可重复读：赃写
串行：
MySQL设置、查看隔离级别
read-uncommitted
read-committed
repeatable read
serializable-- 如何查看事务隔离
SELECT @@global.transaction_isolation;
-- 设置事务隔离性
set global transaction isolation level 隔离性读取未提交
读取未提交：所有事务都可以看到其他未提交事务的执行结果
带来的问题：脏读是某一事务A读取到了事务B未提交的数据。
脏读情况：事务A修改数据，事务B读取数据，事务A回滚数据，则会导致事务B读取的是脏数据。
读以提交
读以提交 ：一个事务只能看见已经提交事务所做的改变。
解决：解决读未提交事务A修改数据，事务B读取数据，事务B读取的数据是原始数据（不是事务A修改后的数据。
带来的问题：不可重复读：在一个事务内，多次读取同一个数据，却返回了不同的结果。
因为在该事务间隔读取数据的期间，有其他事务对这段数据进行了修改并提交
可重读
不可重复读：在一个事务内，多次读取同一个数据，却返回了不同的结果。
因为在该事务间隔读取数据的期间，有其他事务对这段数据进行了修改并提交
解决：事务A多次查看数据中事务B读取数据提交，数据是最初打开事务看到的数据。
带来的问题：事务A查看数据永远是第一次查看的数据，事务B修改数据+500，事务A修改数据+200，就会覆盖之前修改的数据。
可重读的实现机制
可重读带来的脏写的解决方案：乐观锁
事务A获取数据 0，事务B修改数据 +100，事务A修改数据 +200，会覆盖事物B修改的数据。
BEGIN; update account set blance=blance+100 where id=1 and version=2;update account set version=2 where id=1 ; COMMIT;代码修改 判断获取的版本是第一版本才修改。 update account set blance=blance+200 where id=1 and version=1;
可重读带来的脏写的解决方案：在数据库中修改
在数据库修改数据获得最新的数据。
只限于这一张表。
可串行化
-- 事务一 BEGIN; SELECT * FROM account WHERE id=1; COMMIT;-- 事务二 BEGIN; UPDATE account SET balance=balance+500 WHERE id=1; COMMIT;
持久性
Buffer Pool内存写完了，然后会写redo log，redo log 日志记录在那个表修改了什么。
即便MySQL挂了，我们还可以根据redo log 对数据进行恢复。
redo log是顺序写的，写入速度很块，恢复速度也快。
MySQL的事务ACID特性有哪些？
InnoDB引擎中的隔离机制有哪些？
查询数据需要使用事务吗？
如果是可重读事务隔离性，保证所有数据的都是同时性。
对并发性比较高使用RC隔离级别。
传统公司使用RR隔离级别
为什么要写先到redo日志中？
redo日志是按照磁盘顺序写
磁盘文件idb是多个文件在磁盘的不同位置，实现不了磁盘顺序写。
方法)
