MySql的架构和历史

1.1、mysql的逻辑架构

架构为如下：

存储引擎：负责数据的储存和提取，供了几十个API供服务层进行调用。各个存储引擎之间不会进行交互，只是供服务层进行调用。事务控制和锁的管理也是在存储引擎里面进行。

服务层：一个sql过来之后，会在服务层进行解析，建立解析树，调用底层的存储引擎得到各种开销信息和统计信息，进行各种优化，决定表的读取顺序以及选择合适的索引。

1.2  并发控制

1、 mysql通过加读锁和写锁来进行并发控制。

2、锁的粒度

表锁      并发程度低，锁的开销小                  alter table  会加表锁

行级锁   并发程度高，但是锁的开销大

3、锁的控制是在存储引擎里面实现的，所以不同的存储引擎加锁的顺序是不一样的，有的能引起死锁有的则不会。

1.3事务

事务的ACID属性

原子性：一个事务的操作要么全部执行成功，要么全部失败回滚。

一致性：在执行事务的第3,4条语句的时候数据库崩溃了，数据还是一致的。

隔离性：一个事务的操作对另一个事务的可见性。Mysql默认为可重复读。

持久性：一旦事务提交，其所做的修改就会永久的同步到数据库中。

1.3.1隔离级别

read  uncommited（读未提交）   造成脏读

read commited（提交读）        造成不可重复读

oracle和sql  server默认是这种级别

repeatable    read（可重复读）   造成幻读

mysql默认是此级别（通过MVCC和锁机制）

mysql通过mvcc和间隙锁解决了幻读的问题

seriable（可串行化）

事务是串行执行的

1.3.2死锁

因为请求资源的方式不一致可能导致死锁

数据库系统实现死锁检测，解除死锁，和请求锁超时等机制。

如果死锁发生，会将含有最少行级锁的事务进行回滚来解除死锁。

1.3.3  事务日志

因为更新数据到磁盘上数据分布的不均匀，所以花费的时间比较长。但是可以将操作以日志的形式添加到日志文件末尾，日志的存储操作是有序的。这能加快速度。

1.3.4mysql的事务

1、默认每个连接都是AutoCommit，可以在建立连接之后通过命令 show variables  like  'AUTOCOMMIT'来查看当前的状态。

可以通过 set  AUTOCOMMIT=0来设置事务不是自动提交的。那么所有查询都是在一个事务里，直到显式的进行提交或者进行回滚。

2、一些操作会自动提交当前的事务，如alter table，lock   tables

3、设置事务的隔离级别（可以设置全局的和会话级别的）

可以通过set  transaction isolation  level来设置全局的事务隔离级别

可以通过set session      transaction isolation  level  设置本链接的隔离级别，并在下次事务中生效。

1.3.5混合使用存储引擎

1、不推荐这样使用

2、如果一个事务同时操作支持事务的存储引擎表和不支持事务的存储引擎表，如果事务成功提交则没什么问题。如果事务回滚，则支持事务的存储引擎表能回滚，但是不支持事务的存储引擎表不能回滚，会造成数据一致性问题。