浅谈数据库锁机制（数据库 锁机制）

背景：

不管是任何的产品应用，都离不开数据，归根到底都是对数据的处理，因而数据库是必不可少的一个环节，无论是任何类型的数据库。当然，当前主流的还是关系型数据库，如oracle,mysql,db2,sql server等，都是耳熟能详的名字，这些数据库总体来说，虽然各有差异，但主流的必备功能都是还是一致的，这其中就包含锁机制。

什么是数据库锁？

一句话，数据库锁就是针对数据库的操作而制定的规则。

数据库锁分为两种：

乐观锁

自己定义的规则。

常见的做法有两种：版本号和时间戳。

适用的场景：主要是防止对数据库的同一条数据，多次更新。保证同一笔数据只能有一个人对它更新，其他人如果想更新，必须在之前一个更新人的基础上。由此可见，只要前一个更新的时候，加上唯一的可判断前后的标识符，均可实现乐观锁。

悲观锁

数据库定义的规则。

考虑这样一个问题，有了一个数据库，现在大家都可以连接，操作数据库（增删改查），那如果在同一时刻，有两个人都想要对一条数据做修改，那数据库到底听谁的呢？这个时候就需要规则。

悲观锁的类型

共享锁（shared）也称 S锁, 兼容S锁，U锁，排斥X锁。 当一个事务对数据加上共享锁的时候，其他事务对该数据只能被select读取，而不能执行insert，delete，update。

排他锁（exclusive） 也称X锁, 排斥一切锁。当一个事务对数据加上排他锁的时候，其他事务不能对该数据执行任何操作，只能等待锁被释放。

更新锁（updated）也称U锁, 兼容S锁，排斥X锁，U锁。在U锁出来之前，对数据库的更新采取的是S锁+X锁的方式。要想更新，查找是第一步，一般对这一步加S锁，等到更新的时候升级为X锁。但这种操作有时候会导致【死锁】，当有两个事务同时对一条数据更新时，由于刚开始是S锁，两个事务都可以加上锁，但当更新时，升级到X锁时，都需要对方释放S锁，导致死锁。加入U锁后，可以避免死锁。

意向锁 （intension） 意向锁是对共享锁，排他锁的优化，所以意向锁也分为意向共享锁，意向排他锁。

考虑以下场景：

事务A读取表中的一行数据，假设对这一行加了共享锁

事务B往表中插入一行数据，这时候，事务B需要做两件事：

1.判断表有没有加锁

2.判断每一行有没有加锁（逐行判断）

显然第二部的效率时非常低的，那如果A加锁的时候标记一下，那么以上步骤就简单了

1.判断表有没有加锁

2.判断有无意向锁

补充一点，很多人有疑问的地方（我的理解）

什么是事务？

从上一次commit或rollback 到 下一次commit或rollback称作一次事务，中间可能包括0条或多条对数据库的操作。

查询是否开启事务？

如果设置为自动提交，select开启事务没有意义，因为并未涉及到数据库的修改，没有必要commit或rollback。

如果设置为手动提交，按照我上面的说法，肯定是要开启事务的，因为我们有commit或rollback的处理。

行锁与表锁

行锁，即对需要的行进行加锁，不加锁的行其他事务仍然可以进行操作。

优点：并发性高，可多个事务操作一张表。

缺点：实现复杂，加锁开销大。

表锁，即对整张表进行加锁，其他事务，不可再对该表进行操作。

优点：实现相对简单，加锁开销小。

缺点：并发性低，同一时刻只能有一个事务操作该表。

所以，行锁，表锁，各有优缺点，使用时也应根据实际情况而定。

事务的隔离级别，或多或少跟锁也有关系

uncommitted_read : 未提交可读。未提交的数据其实是在内存中，并未写入数据库文件。所以这种方式时内存优先，会先去内存中查找数据，如果有，直接返回，不会查数据库。数据库不加任何锁，所以会出现脏读，不可重复读，幻读等问题。

committed_read：提交可读。直接查数据库，可避免脏读，但同样没有加锁，会出现不可重复度，幻读。

repeatable：可重复读。直接查数据库，可避免脏读，对读加锁，不允许更新，但允许插入，所以可避免不可重复读。但会出现幻读。

serializable: 串行化。直接查数据库，可避免脏读。事务按顺序执行，可避免不可重复读，幻读。

上述所讲的皆是概念性的东西，加锁目的不言而喻，保证数据的准确性！具体的实现，不同的数据库可能不同，处理问题，也要视情况而定！

PS

以上内容，都是我个人的理解，如果有不对的地方，欢迎批评指正！