mysql第二天锁

如果没有锁，那么并发性会更强，但是数据安全性会有问题。因此数据库会给数据加锁。

共享锁与排他锁

也就是读写锁，共享锁可以叠加共享锁但是不能加排他锁， 排他锁则不能叠加。
根据隔离级别等等，mysql会隐式的给数据自动加锁
此外还可以使用share in model, for update 等语句显示的加锁

粒度锁

粒度越细，维护锁的开销越大，并发性越高，数据越不安全。 通常有如下两种
- 行锁
只给一行数据加锁
- 表锁
给整张表加锁， 一般Alter table会使用表锁

意向锁

mysql为了提高冲突监测性能而存在的一种锁。是给其上一级所加的锁，所以在mysql中通常为表锁。
比如一个事务，给两行加了排他锁，又有一个事务想要给整个表加共享锁，这个时候就要去查看所有的表的行是否有锁策略不能加共享锁。 如果有了意向锁，那么事务1就能再给两行加排他锁的同时，给整个表加IX， 这样事务2不用遍历就能知道不可以加S锁了。

悲观锁与乐观锁

A,B两个人同时在系统上进行操作，比如要修改一份订单。 当A正在修改准备提交前向上厕所，这儿时候B修改完订单并且提交了。 这个时候A回来了再提交就会出现问题，B的修改被覆盖了。
- 悲观锁
for update, share in model语句
使用悲观锁，则会在操作期间全程对数据进行加锁，其他人不能再次修改。这样会造成比较长时间的阻塞。
适用于短事务，写量比较大的情况。
- 乐观锁
乐观锁通过在数据库中新增一个version字段，操作后给version + 1. 提交时比较，如果比数据库中的大，则提交。大概的代码是：

    if(connection.update("update set name='123' where id=1 and version < #current_version#") > 0){
        // 表示更新成功了
    }

这种适用于读多，写少，并且写有可能会用很长时间的情况。

死锁

比如有两个事物:
事物1

update table1 set name='1' where id=1;
// sleep 1
update table1 set name='2' where id=2;
commit;

事物2

update table1 set name='2' where id=2;
// sleep 2
update table1 set name='1' where id=1;
commit;

上面的语句如果恰巧一起执行到sleep1 和sleep2，那么就会造成死锁。 一般有三种做法解决：

间隙锁

执行select .. from where id between这样的语句的时候锁定这一区间，不能插入或者删除数据，以防止幻读。

MVCC 多版本并发控制

mysql维护一个系统版本号，每次有新的事物开始的时候递增。
每行后面保存两个隐藏列。 一个创建时版本号C，一个删除时版本号D

语句与锁

 set autocommit=0;
 begin;
 SELECT * FROM biz_pay_task where id = 1 FOR UPDATE;
 // wait
 commit;

事务2

 set autocommit=0;
 begin;
 SELECT * FROM biz_pay_task where id = 1 LOCK IN SHARE MODE;
 commit;

事务2在执行SELECT LOCK IN SHARE MODE的时候会阻塞，知道事务1commit之后才会完成。