database lock

transaction

事务 - 最小逻辑工作单位。事务不能嵌套

  • ACID （important）
    consistency 一致性 - DB只包含成功提交的事务的结构。事务在执行前后都保持一致性状态，在一致性状态下，所有事务对一个数据的读取结果都是相同的；（most important，只有满足一致性，事务的执行结果才是正确的）
    atomicity 原子性 - 事务中含有的许多操作，要么都做，要么都不做（失败回滚）。
    isolation 隔离性 - 事务所做的修改在最终提交以前，对其他事务是不可见的 。在并发中，在未成功提交前，其他事务不可见。
    durability 持久性 - 一旦成功提交的事务，操作永久有效, 即使系统发生崩溃，事务执行的结果也不会丢失。应对DB崩溃情况。
    串行化可以解决所有问题，但是性能不足。
    串行：满足原子性 -> 一致性
    并发： 满足原子性、隔离性 -> 一致性

MySQL:
START TRANSACTION or BEGIN [WORK]
COMMIT [WORK]
ROLLBACK [WORK]
SET autocommit = {0 | 1}

默认自动提交，每一个语句为一个事务

并发一致性问题

  • 丢失修改 - 多个修改 （X）
  • 读脏数据 - 修改后撤销了 （S， X）
  • 不可重复读 - update （S， X）
  • 幻读 - insert，delete （串行化）

事务的隔离级别

  • read uncommitted - do nothing
  • read committed
  • repeated read
  • serialization

lock

  • 三级封锁

  • 两段锁协议（遵守两段锁协议的事务可能发生死锁）：扩展和收缩阶段

事务遵循两段锁协议是保证可串行化调度的充分条件
并发调度的可串行性： 与某一次串行执行的结果相同
并发控制技术
个事务的失败可能会引起一连串事务的回滚
  • 一次封锁法 遵循两段锁协议，同时将所要使用的资源，一次性全部加锁。可以避免死锁。
  • type
    共享锁（S锁，读锁） - 可加S lock
    排他锁（X锁，写锁） - 不可S，X锁
    意向锁（表锁 IS， IX） -更容易地支持多粒度封锁.  IS or IX -> S; IX -> X
    悲观锁 - 保守态度，依靠数据库提供的锁机制（S， X）
    乐观锁 - 只会对数据进行提交更新的时候，才会正式对数据的冲突与否进行检测
    ​    版本号（数据更新 version+1. version-read == version-update ? or not）
    ​    时间戳（数据更新时间）

  • 活锁和死锁

  • 封锁的粒度

    封锁的粒度越小，锁定的数据量越少，发生锁争用的可能就越小，并发程度越高；
    封锁的粒度越小，系统开销越大
    行级锁 vs 表级锁

reference

transanction & lock