mysql 锁机制

mysql的锁机制

含义：锁是计算机协调多个进程或线程并发访问某一资源的机制

在数据库中，除了传统的计算资源（如CPU,RAM,I/O等）的争用之外，数据也是一种用户共享的资源。如何保证数据并发访问的一直型、有效性是所有数据库必须解决的问题，锁冲突也是影响数据库并发访问性能的一个重要因素。因而，锁对数据库很重要。

 

分类

按照操作来分：读/写锁

读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会相互影响。

写锁（排他锁）：当前写操作没有完成前，他会阻断其他写锁和读锁。

#查看表上加着的锁
show open tables;

#手动增加表锁
lock table 表名1 read(write), 表名2 read(write),其他；

#释放锁
unlock tables;

#加了读锁（共享锁）之后
lock table 表1 read;
在加锁的session1中：
1.可以读自己吗？
可以
2.可以修改表的内容吗？
不可以！！！！！！！！！！！！会报错error
3.可以读别人吗？
不可以！！！！！！！！！！！


在另外一个session2中：
1.可以读session1中的读锁表吗？
可以
2.可以修改表的内容吗？
不可以！！！！！！！！！！！！会出现阻塞（一直等待）
3.可以读别人吗？
可以！


#加了写锁（排他锁）之后
lock table 表1 write;

在加锁的session1中：
1.可以读自己吗？
可以
2.可以修改表的内容吗？
可以！！
3.可以读别人吗？
不可以！！！！！！！！！！！


在另外一个session2中：
1.可以读session1中的读锁表吗？
不可以，会出现阻塞，需要等待锁被释放
2.可以修改表的内容吗？
不可以！！！！！！！！！！！！会出现阻塞（一直等待）
3.可以读别人吗？
可以！

 

 

总结：

1.对于myisam表的读锁，不会阻塞其他进程对同一表的读请求，但是会阻塞对同一表的写请求。当读锁释放后，才会执行其他进程的写操作

2.对于myisam表的写锁，会阻塞其他进程对同一表的读和写请求，当写锁释放后，才会执行其他进程的读写操作

简而言之：读锁会阻塞写，但是不会阻塞读，而写锁会把读和写均阻塞！！！！

 

按照粒度分：表锁/行锁

表锁（偏读）

特点：偏向myisam存储引擎，开销小，加锁快；无死锁；锁定力度大，发生锁冲突概率最高，并发度低。

 

#查看表上加着的锁
show open tables;

#如何分析表锁定
可以通过检查table_locks_waited 和 table_locks_immediate 状态变量来分析系统上的表锁定；
show status like "table%"

table_locks_immediate ：产生表级锁定的次数
table_locks_waited ：出现表级锁定争用而发生等待的次数（不能立即获取锁的次数，每等待一次锁值加1），此值高则说明存在严重的表级锁争夺情况。

　　

行锁（偏写）：

特点：偏向innodb存储引擎，开销大，加锁慢；会出现死锁；锁定力度最小，发生锁冲突概率最低，并发度高。

innodb与myisam的最大不同：（1）支持事务；（2）采用行级锁

#锁定某一行的代码
#step1:行锁开始的标志
begin;

#step2:人为为某一行上锁
select * from 表名 where 字段=啥 for update;

#step3:修改完数据后，提交（在没有提交之前，其他session对此行操作会阻塞）
commit;

　　

 间隙锁（宁可错杀，不可放过）

当我们用范围条件而不是相等条件检索数据，并请求共享和排他锁时，innodb会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙”（GAP）,

INNODB也会对这个‘间隙"加锁，这就是间隙锁（next-key锁）

危害

因为query执行过程中通过范围查找的话，他会锁定整个范围内的索引键值，即使这个键值不存在

所以在锁定的过程中，如法插入锁定键值范围内的任何数据。

 

行锁总结：

show status like "innodb_row_lock%";

#执行上句出现的结果
innodb_row_lock_time_avg(等待平均时长)

innodb_row_lock_waits:系统启动后到现在总共等待的次数（等待总次数）

innodb_row_lock_time:(等待总时长)

　

 

页锁：

开销和加锁时间介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般。

 

 

10.乐观锁和悲观锁

乐观锁：每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
悲观锁：每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。