MySQL 的查询流程一般是: MySQL 客户端通过协议与 MySQL 服务器建立连接, 发送查询语句, 先检查查询缓存, 如果命中, 直接返回结果, 否则进行语句解析, 有一系列预处理, 比如检查语句是否写正确了, 然后是查询优化(比如是否使用索引扫描, 如果是一个不可能的条件, 则提前终
止), 生成查询计划, 然后查询引擎启动, 开始执行查询, 从底层存储引擎调用 API 获取数据, 最后返回给客户端. 怎么存数据, 怎么取数据, 都与存储引擎有关.
MySQL 乐观锁来解决并发问题
乐观锁( Optimistic Locking ) 相对悲观锁而言, 乐观锁假设认为数据一般情况下不会造成冲突, 所以在数据进行提交更新的时候, 才会正式对数据的冲突与否进行检测, 如果发现冲突了, 则让返回用户错误的信息, 让用户决定如何去做. 那么我们如何实现乐观锁呢, 一般来说有以下 2 种方式:
1, 使用版本号实现乐观锁
版本号的实现方式有两种, 一个是数据版本机制(自己参与的项目基本采用的是 version), 一个是时间戳机制. 具体如下.
a. 使用数据版本 (Version) 记录机制实现, 这是乐观锁最常用的一种实现方式. 何谓数据版本? 即为数据增加一个版本标识, 一般是通过为数据库表增加一个数字类型的 "version" 字段来实现. 当读取数据时, 将 version 字段的值一同读出, 数据每更新一次, 对此 version 值加一. 当我们提交更新的时候, 判断数据库表对应记录的当前版本信息与第一次取出来的 version 值进行比对, 如果数据库表当前版本号与第一次取出来的 version 值相等, 则予以更新, 否则认为是过期数据. 如果更新操作顺序执行, 则数据的版本 (version) 依次递增, 不会产生冲突. 但是如果发生有不同的业务操作对同一版本的数据进行修改, 那么, 先提交的操作会把数据 version 更新为 2, 当 A 在 B 之后提交更新时发现数据的 version 已经被修改了, 那么 A 的更新操作会失败.
b. 时间戳机制, 同样是在需要乐观锁控制的 table 中增加一个字段, 名称无所谓, 字段类型使用时间戳(timestamp), 和上面的 version 类似, 也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比, 如果一致则 OK, 否则就是版本冲突.
来源: http://www.bubuko.com/infodetail-3651326.html