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,太高的隔离级别影响效率,太低又容易引发重大错误