mysql-锁机制

1、什么是锁？

    就是数据库为了保证数据的一致性，而使各种共享资源在被并发访问时变得有序所设计的一种规则

2、锁的类型？

从数据的操作类型来看：读锁、写锁

从数据操作的粒度分：表锁、行锁

    表级锁

    行级锁

    页级锁

2.1、读锁：共享锁，针对同一份数据，多个读操作可以同时进行而不会互相干扰

读锁的演示：

步骤1：建表和插入数据

create table mylock(

    id int not null primary key auto_increment,

    name varchar(20)

) engine=myisam charset utf8;

insert into mylock (name) values ('a');

insert into mylock (name) values ('b');

insert into mylock (name) values ('c');

insert into mylock (name) values ('d');

insert into mylock (name) values ('e');

insert into mylock (name) values ('f');

select * from mylock;

create table book(

    id int not null primary key auto_increment,

    title varchar(20),

    author varchar(20)

) engine=myisam charset utf8;

insert into book(title, author) values ('a', 'ling-a');

insert into book(title, author) values ('b', 'ling-b');

insert into book(title, author) values ('c', 'ling-c');

insert into book(title, author) values ('d', 'ling-d');

insert into book(title, author) values ('e', 'ling-e');

insert into book(title, author) values ('f', 'ling-f');

select * from book;

更改表的引擎：alter table book engine=innodb

手动增加表锁：lock table tblname read|write, tbl2 read|write

查看表上加过的锁：show open tables；

步骤2：给表加锁和解锁

lock table mylock read, book write;

show open table;

unlock tables;

A：session 1，B：session 2

给表加读锁的情况：

A：lock table mylock read

A：select * from mylock  - ok

A：update mylock set name='a2' where id = 1; - no ok

A：select * from book； -- no ok

B：select * from mylock  - ok

B：update mylock set name='a3' where id = 1; -- 出现了阻塞问题，等到mylock的锁被释放后，才能执行此操作

    unlock tables；后，B会话会执行

总结得：

    获得表mylock的read锁定；

    当前会话可以查询该表记录，其他会话也可查询该表记录；

    当前会话不能查询其他没有锁定的表，其他会话可以查询或者更新未锁定的表；

    当前会话中插入或更新锁定的表都会提示错误，其他会话插入或更新锁定的表会一直等待获取锁；

    当前会话释放锁后，其他会话操作才可完成

给表加写锁的情况：

A：lock table mylock write;

A：select * from mylock write; - ok

A：update mylock set name='a3' where id = 1; - ok

A：select * from book; - 报错

B：select * from book; - ok

B：select * from mylock; - 阻塞

    unlock tables; 会直接获取结果

总结得：

    当前会话对锁定表的查询+更新+插入操作都可以执行，其他会话对锁定表的查询被阻塞，需要等待锁被释放

    当前会话释放锁，其他会话执行解除阻塞

结论：MySQL的表级锁有两种模式：表共享读锁，表独占读锁

读锁不会阻塞其他进程对同一表的读操作，但会阻塞对同一表的写操作，只有当锁释放后才会执行其他进程的写操作

写锁会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其他进程的读写操作

注意：读锁会阻塞写，但不会阻塞读；而写锁会把读和写都阻塞

表锁分析：

show open tables; - 查看表被锁定的状态，0：为不被锁定，1：被锁定

show status like 'table%';

table_locks_immediate：产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取值为1；

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

MyISAM的读写调度是写优先，这也是MyISAM不适合做写为主表的引擎。因为写锁后，其他线程不能做任何操作，大量的更新会是查询很难得到锁，从而造成永远阻塞

2.2、行锁：排他锁当前写操作没有完成前，它会阻断其他写锁和读锁

偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁粒度最小，发生锁冲突的概率最低，并发度也最高

行锁的演示案例：

步骤1：建表及插入数据

id int(11) not null primary key auto_increment,

create table innodb_test(

    a int(11),

    b varchar(16)

)engine=InnoDB charset utf8;

insert into innodb_test values (1,'b2');

insert into innodb_test values (3,'3');

insert into innodb_test values (4,'4000');

insert into innodb_test values (5,'5000');

insert into innodb_test values (6,'6000');

insert into innodb_test values (7,'7000');

insert into innodb_test values (8,'8000');

insert into innodb_test values (9,'9000');

insert into innodb_test values (1,'b1');

create index a_index on innodb_test(a);

create index b_index on innodb_test(b);

select * from innodb_test;

关闭锁的自动提交：set autocommit = 0;

A：session 1，B：session 2

A：set autocommit = 0;

B：set autocommit = 0;

A：select * from innodb_test; - b此时的值是4000

B：select * from innodb_test; - b此时的值是4000

A：update innodb_test set b='4001' where a = 4;

A：select * from innodb_test; - b此时的值是4001

B：select * from innodb_test; - b此时的值是4000

只有当AB会话同时执行commit后，B才能看到A做的更改

A：update innodb_test set b='4002' where a = 4; - 未commit

B：update innodb_test set b='4003' where a = 4；- 阻塞状态

此时只有当A提交、B也提交后，才能看到最终被修改的值

总结得：A更新但是不提交，没有手写commit；B被阻塞，只能等待A提交更新，解除阻塞更新正常进行

A更新a=1，B更新a=9

A：update innodb_test set b='4005' where a = 4; - 与B互不干扰

B：update innodb_test set b='9001' where a = 9; - 与A互不干扰

失效行锁变表锁的情况：字符串类型的字段不加引号带来的问题之一

A：select * from innodb_test;

A：update innodb_test set a = 41 where b='4005' ;

B：update innodb_test set b = '9002' where a=9;

A：update innodb_test set a = 41 where b=4005 ; # b是varchar类型 成功

B：update innodb_test set b = '9003' where a=9; # 此时阻塞导致行锁变成表锁

分析行锁：

通过innodb_row_lock状态来分析系统上的行锁的争夺情况：

show status like 'Innodb_row_lock%';

Innodb_row_lock_current_waits：当前正在等待锁定的数量

Innodb_row_lock_time：从系统启动到现在锁定总时间长度

Innodb_row_lock_time_avg：每次等待所花平均时间

Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花时间

Innodb_row_lock_waits：系统启动后到现在总共等待的次数

优化建议：

    尽可能让所有数据检索都通过索引来完成，避免将索引行锁升级为表锁

    合理设计索引，尽量缩小锁的范围

    尽可能较少范围检索条件，避免间隙锁

    尽量控制事务大小，减少锁定资源量和时间长度

    尽可能低级别事务隔离

2.3、间隙锁

带来的问题：

A：update innodb_test set b='111' where a > 1 and a < 6;

B：insert into innodb_test values (2, '2000'); -  阻塞

当A和Bcommit提交之后，查询发现新插入的2的值未被更改成111

什么是间隙锁：

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

InnoDB会对这个间隙加锁，这种锁机制就是所谓的间隙锁

间隙锁的危害：

    因为query执行过程中通过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值并不存在，间隙锁有一个比较致命 弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害