MySql简单对事务和引擎的理解

事务（ACID）

1、原子性（atomicity）：不可分割的整体；
2、一致性（consistency）：类似于能量守恒，一方多，另外一方必定少，系统的总数不会发生改变；
3、隔离性（isolation）：并发，事务之间互相隔离，有四种级别；
4、持久性（durablity）：事务对数据库的修改具有持久性。其中，增删改查对文件的操作，都是具有持久性的。
事务：一条或者多条sql语句组成，要么都是成功，要么所有的sql语句都是失败的。

只要事务开启，所有的操作就会在缓存中执行，当插入一条数据时，查询依然可以找到。如果一条操作失败，则调用rollback退回到文件中的初始状态就行。

使用事务的步骤

1、更改储存引擎为InnoDB；
2、开启事务；
3、输入组成事务的SQL语句；
4、如果语句执行失败，可以调用rollback，回退到文件的初始状态
5、当所有的SQL语句执行成功的时候，调用commit，提交数据，修改文件的数据为最新数据。如果提交事务之后，就不能够rollback。

开启事务

1、select @AutoCommit
首先查看是否开启默认提交，如果为1，表示每次对数据的操作，都会提交给文件。对于事务，就不能够rollback。
2、set @AutoCommit = 0，表示关闭自动提交，当所有的sql执行完成的时候，手动提交。
3、begin
表示开启了事务，下一条sql将在缓存中执行。
4、commit
成功执行完所有的sql语句，提交到文件中。
Rollback：如果有sql语句执行失败，就回退到文件最初的状态
savePoint：设置保存点，有的时候，虽然SQL语句执行失败，但是没有必要回退到最初状态
rollback to 保存点名：回退到保存点的状态
commit：执行成功所有的sql语句，提交给文件。

事务的隔离性所发生的问题

1、脏读： rollback select t2读取到t1未提交的数据；
2、不可重复读：t1设置age=15，update age = 16，t2读取到之前的15；
3、虚读/幻读： delete和insert引起的问题

t2 select可查到user1，user2     t1 delete user1
t2只能读到user2
t2 select可查到user1，user2     t1 insert user4
t2可读到 user1，user2，user4

事务隔离级别

1、不支持事务
2、支持事务的

需要注意的是：隔离级别越高，效率越低

储存引擎

MyIsam：Mysql默认的引擎，不支持事务
InnoDB：支持事务，可以通过SQL语句或者配置文件进行修改

更改引擎的方法：

1、创建表的时候
Create table user（id int）ENGINE=InnoDB；
2、对已经存在的表修改
Alter table 表名 ENGINE= InnoDB；
3、配置文件修改
Default—storage—engine = InnoDB；
如果修改的是配置文件，那么就一定要重启mysql

如何提高mysql的执行效率？

使用mysql索引
索引
数据结构为b+树，称为多路排序树，查询效率log m（n）
作用：类似于字典目录，通过索引找数据
表的创建—>通过属性创建---->排序（对一个或者多个属性）

B+树和B树

1、b+树容易控制高度，mysql限制索引树的高度不能够超过三层；
2、b+树对所有数据的查询效率都是平均的，b+树只在叶子结点存放数据，非叶子结点存放关键字（索引），b树同时存放索引和数据
3、b+树用链表将叶子结点连接起来，适合做范围查询和排序。

几种数据结构的对比区别

B+树和数组

1、要查询一个索引，首先进行快排（nlongn），然后二分查找（long2（n）），查询效率低；
2、使用连续的内存，空间不足

B+树和链表

1、查询效率低

B+树和二叉排序树

1、查询效率低，平均为log2（n），但是容易退化为链表
2、索引从文件加载到内存中IO耗时，一次只能加载一个结点

B+树和平衡二叉树

1、虽然不会退化为链表，但是旋转的次数太多，几乎每添加一个索引，就要旋转一次，索引的树结构变化的太过于频繁
2、索引从文件加载到内存中IO耗时，一次只能加载一个结点

B+树和红黑树

1、可以降低旋转的次数，但是查询效率还是太低
2、索引从文件加载到内存中IO耗时，一次只能加载一个结点

问题

hashMap中为什么不用b+树代替红黑树？
1、链表上的个数不会太多，没有必要使用b+树（加载因子*容量>阈值，就会扩容）
2、hashMap不用排序