事务和并发执行目的：

1、提高吞吐量，资源利用率

2、减少等待时间

连接管理器:接受请求/创建线程/认证用户/建立安全连接

并发控制：任何时候，只要有两个以上的用户试图读写同时一个文件/数据，都会带来并发控制问题，

多版本并发控制(MVCC)：每个用户在操作数据的时候操作的都不是源数据，而是操作的是源数据的副本/快照，最后再把操作的快照合并到源数据上去

锁：最简单的并发控制机制就是实施锁|要想实现并发控制一个基础的工具就是"锁"

读锁(read)：共享锁，允许其他人同时读，但不允许写！

写锁(write)：独占锁，写的时候，既不允许其他人写，也不予许其他人读！

加锁：lock   tables    表名   锁类型{read|write}

解锁：unlock   tables    ：表示解除所有表的锁

锁粒度：从大到小（mysql服务器仅支持表锁，行锁需要有存储引擎的支持）

表锁：一下子锁定一张表

页锁：锁定一个数据块，页面。

行锁：

注意！：平常不需要给表手动添加锁，大多数情况下mysql内部就维持锁。

事务

存储引擎或服务器要支持事务必须满足4种测试，叫ACID测试

ACID

原子性：事务所引起的数据库操作，要么完全的反应出来，要么完全的都不反应！

一致性：事务在完成之前或之后结果是一致的，当事务结束之后，整个数据库服务器的状态是没有改变的

隔离性：事物之间影响最小，一个事务的中间过程，不能影响到另一个事务的正常执行过程

持久性：服务器出现崩溃了，仍然要保证数据在下一次恢复过来之后，仍然是有效的！，那也就意味着在内存运行完的数据要立即同步到存储设备上去！

1、事务提交之前就已经写出数据至持久性存储

2、结合事务日志完成，事务产生的是顺序IO(按次序存储到连续的存储块当中去)。数据文件是随机IO。

3、

事务日志

自我能够完成重做或撤销，在必要的时候进行自我修复

在事务引擎上，为了完成我们mysql事务，他的每一次操作都是首先在日志文件中完成。

也就意味着我们的增、删、查、修改都是在内存中完成，完成之后立即写到事务日志中去。过一段时间才会写到磁盘空间中去！

重做日志(redo  log)：我们的每一个操作，在真正写到数据库之前，他先写到日志里面去，下一次我们这个操作就算是崩溃了，他还可以根据我们的操作日志重新走一遍。

我们这一系列操作可以无限次的根据这个日志重复的执行N遍。

撤销日志(undo  log)：我们的每一次操作，在操作之前要把它原有的状态给他保留下来，万一将来我们需要还原回原来状态时，可以给他撤销此前所做的任何一个操作，

这些日志最终的目的是：为事务提供ACID兼容性的

事务状态

活动的：active

部分提交

失败的

终止的

提交的

隔离性：

隔离级别(级别从低到高)：

READ  UNCOMMITTED读未提交：读取数据不需要加S锁，这样就不会跟被修改的数据上的X锁冲突

READ  COMMITTED 读提交：别人只有提交之后，你才能看到

REPATABLE  READ可重读：不管你提不提交数据，我这里第一次看到是什么样，一直到事务完成之后还是那个样。

SERIALIZABLE  可串行：

mysql默认隔离级别为REPATABLE  READ可重读

查看隔离级别：show global variables like '%iso%';

修改隔离级别：set  {session|global} 变量名='对应值'; |set tx_isolation='read-committed';

并发控制依赖的技术手段：

锁

时间戳

多版本和快照隔离

事务命令

启动事务：start  transaction;

回滚/撤销事务：rollback;

提交事务：commit

查看是否启动自动提交：select @@autocommit;

关闭自动提交：set autocommit=0;

事务支持保存点