事务和并发执行目的： 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;   事务支持保存点