mysql锁与程序锁_数据库层面的锁和应用层面的锁有什么区别？

先说共同点:都是为了数据安全和突破吞吐量瓶颈设计的.

区别:

数据库层面的锁一般叫悲观锁,为什么呢?因为它很悲观的认为,自己的数据一直是不安全的,每次数据操作时,一定会有其他程序也来修改自己.

程序层面的锁一般叫乐观锁,为什么?因为它很乐观的认为,自己在修改数据时,不会有其他程序也来修改.

正是基于乐观和悲观的情况,设计出两种锁机制.

先说数据库层面,既然数据库认定自己的数据不安全,可能会出现两个程序同时修改自己的可能,那么他怎么避免这种情况呢?

数据库说了,我为每个数据准备三把锁头,一把叫共享锁,一把叫排他锁,一把叫更新锁.

共享锁:你如果只是读数据,请加上这把锁,这样别的程序禁止修改这个数据,别的数据也能加共享锁来读.

排它锁:你要修改数据,那么加排它锁,让别人连读都读不了,你先改,改完了,把锁去了,别人才能加共享锁来读.

更新锁:介于共享锁和排他锁之间的锁,用来避免两人同时申请排它锁造成死锁问题的锁.

这是数据库层面的锁.而你要问为啥要加锁,这是避免几种脏读,幻读,不可重复读的手段,具体请再追问吧.

数据库层面的锁是默认的,你没法去选择,数据库就是这个机制.

但应用层面的,你可以自己通过程序,手段来达成,也就是说,程序层面的,你不写,就没有锁.

那程序层面的锁怎么实现呢?

首先,程序层面的锁叫乐观锁.他很乐观,因为他觉得,我在读数据的时候,没有人会来修改我的数据,所以我读的数据是安全的,不会出现我先读一个数据,别人修改了,我再读不一样的问题.

所以程序很乐观.但是乐观归乐观,他只是期待不出现这种情况,但是墨菲定律告诉我们,小概率事件也会出现的.所以程序还是要避免这种情况.

那么程序层面的锁就出现了.怎么实现呢?

一般是为数据加一个version字段,每次修改数据时,就将这个字段+1,这样的好处在于下面的设计.

A程序要修改某个字段,修改前要读取其有效字段,和version字段,假设当前version字段是10,然后A程序拿着数据去操作了,操作完了,要修改这个数据,按理说A程序操作完这个数据,要给version+1,意思,我改了一次.但是他真正提交数据前,还要再读取一次version,看看还是不是10,因为如果不是10了,说明,在我拿着数据去操作的过程中,有个小逼崽子也操作了这个数据,并且已经修改了这个数据,那么我刚才做的这一些岂不是都是无用功?

所以这时候,我还修改数据干啥?

这个version就是程序定义出来的多出来的字段,用来给程序去判断,这条数据现在安全么,是不是可靠可修改的数据.

如果我前后读到的version是一个值,说明没人来干扰,那么我就可以放心的提交事务,修改数据了.

这就是程序层面的锁机制.他是需要去判断一下是不是有人参与的数据的操作.没人参与就没人嘛,那正好了,我修改我的.有人参与,再说怎么办.

大概的区别就是这样的,数据库的锁,无论你愿不愿意,我都给你加锁保证安全.程序的锁,是读取数据大于修改数据的时候,我给你保障你的数据安全.

其实我也想不出多简单明了的解释,所以多啰嗦两边,看看用不同的话解释你能明白不.

程序的锁就是太乐观了,所以一般情况下,我是不加锁的,只有我设计的这个机制告诉我,有人也改了数据,我才需要做响应的反应,是回滚还是怎么滴.严格来说,以我的经验,我不认为程序的这个叫锁,因为他没有锁定数据,他顶多叫预警器,告诉你,你的数据现在的状态,具体这个状态有什么意义,是你程序员自己判断去.我不管.

打了好多,也查了很多知识,不知道有没有帮助,不懂再问我吧

哦,在完善一下,怎么加锁啊.

最简单的数据库:update User set name="新数据" where id=3;

这样的会自动加上排他锁,不需要你写,数据库会自动根据你的sql关键字,update,select,delete,insert进行加响应的锁,当然,你也可以显示的主动锁定某个表,或者字段,使用不同的锁,都可以,显示加锁自己百度下.

然后程序层面的,用刚才我说的version字段值判断也行,或者直接加个lock字段,操作数据时,将数lock改为true,然后你操作你的,其他程序操作前,也是要判断是否为true,是,就不操作,等着,轮训到false,再改成true,操作.

其实数据库层面的锁,已经是很悲观的了,把糟糕差的情况都帮你想到了,最差的处理了,你程序层面不加锁一般也没事,但是一般没事,加个乐观锁,能进一步保证数据安全,也不错啊.数据库锁就是社保,程序锁就是商业保险.