mysql架构

1.连接/线程处理
连接数据库部分
2.解析器 优化器 查询缓存
优化查询语句
3.存储引擎
存储数据，当有查询语句进来，我们根据查询语句的要求将数据返回就行了，但是我们知道不仅仅只有查询语句，还有修改 删除 添加等语句，如果只能一个sql进来我们直接按他要求办事就行了，如果有两个语句想要同时修改一处的数据时就发生问题了，有人说这好解决并发问题加个锁就完事了，然而在实际操作中，如何加锁让整个mysql更有效率是个值得让人思考的问题，
1.首先我们知道sql语句读写之分，再多并发去读同一块数据都不会面临着并发问题，而写与写之间和写与读之间面临并发问题，所以读锁是共享的，而写锁排他的，写sql在执行的时候是不能进行其他读写操作。
2.我们知道数据库是由数据库 数据库表 数据库表中的字段这样一个总 分 的结构组成，在何种结构上加锁，也可以理解为锁的粒度的大小如何设计能让业务工作更有效率，正常来说我们设置的锁粒度越小，那么在整个并发查询的等待时间越短，那么将粒度尽可能的小不就行了吗？但是正如你所知，加锁是消耗资源的，数据库是存储数据的，不是一直在处理获取锁 释放锁等过程的，我们必须在锁的粒度与锁的开销的比重做出平衡，mysql的设计师是聪明的，他把这个任务的选择权力教给了我们，我们根据实际业务也选择锁的粒度，目前锁的粒度有行级锁与表级锁

上面仅仅是讨论的一条sql语句的执行，一条sql语句与另一条sql语句之间的并发冲突处理的方式的讨论，但是事实上在业务中，一组sql语句的执行构成了我们整个的数据库接口调用方法，第二层的解析器 优化器会将我们复杂的sql查询分解为一个个小小的构成一组的sql语句传入存储引擎执行，这组sql语句应该是不可分割具有原子性的，也就引出事务的存在意义，这里引用一个经典的例子
银行应用是解释事务必要性的一个经典例子。假设一个银行的数据 库有两张表：支票（checking ）表和储蓄（savings ）表。现在要从用 户Jane的支票账户转移200美元到她的储蓄账户，那么需要至少三个步 骤：1. 检查支票账户的余额高于200美元。 2. 从支票账户余额中减去200美元。 3. 在储蓄账户余额中增加200美元。
上述三个步骤的操作必须打包在一个事务中，任何一个步骤失败， 则必须回滚所有的步骤。其中事务有四个特性
原子性（atomicity）、一致性（consistency）、隔离性 （isolation）和持久性（durability）
其中着重讨论隔离性
隔离性
事务与事务之间的隔离关系，设定了四个隔离级别

隔离级别越高可能出现的问题越少，但是事务因为等待其他事务处理的可能性越高，事实上一般使用的隔离级别为READ CMOMMITTED 和REPEATABLE READ,太高的隔离级别影响效率，太低又容易引发重大错误