锁的类型
共享锁(S)
共享锁可以被多个事务持有，事务T1获取了行r的共享锁，那么事务T2也可以获得行r的共享锁，但是获取不到事务T1的排它锁
显示的加共享锁：select * from xx lock in share mode;
排它锁(X)
排他锁只能被一个事务持有，事务T1持有了行r的排它锁，那么事务T2获取不到行r的排它锁，也获取不到行r的共享锁
显式的加排它锁：select * from xx for update;
|
S |
X | |
|---|---|---|
|
S |
兼容 |
不兼容 |
|
X |
不兼容 |
不兼容 |
创建一张测试表a,id是主键，a2为唯一索引，a3为普通所以
CREATE TABLE `a` ( `id` int(11) NOT NULL AUTO_INCREMENT , a1 int(11) NOT NULL , a2 int(11) not NULL, a3 int(11) not null, PRIMARY KEY (`id`), unique key uniq_a2(a2), index idx_a3(a3) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ; insert into a(a1,a2,a3) values(1,2,3),(2,4,6),(3,6,12);
事务1获取共享锁，事务2获取排它锁，事务2将获取失败
|
事务1 |
事务2 |
|---|---|
|
start TRANSACTION; select * from a where id=2 lock in share mode; |
|
|
获取S锁成功 |
|
|
start TRANSACTION; select * from a where id=2 for update; |
|
|
等待... |
|
|
获取X锁超时（Lock wait timeout exceeded; try restarting transaction） |
|
|
commit; |
|
|
start TRANSACTION; select * from a where id=2 for update; |
|
在事务2等待锁过程中执行 select * from information_schema.innodb_trx; 查看锁当前状态，可以看到事务1处于RUNNING状态，事务2处于LOCK WAIT状态
其中trx_weight表示事务的权重，反应了一个事务修改和锁住的行数。在INNODB中，当发生死锁需要回滚时，InnoDB会选择该值最小的进行回滚，因为这个值越小需要进行回滚操作的数据越少
在事务2等待锁过程中执行 select * from information_schema.innodb_locks 查看锁信息，lock_data表示事务锁定的主键的值，由于查询条件是id=2,因此lock_data=2,由于两个事务对同一行记录分别申请S所和X锁，因此会发生等待
lock_rec 事务锁定行的数量（明明是按主键锁主了一条记录，为什么这里的lock_rec是3）
lock_page 事务锁定页的数量
使用 select * from information_schema.innodb_lock_waits; 查看信息，可以看到那些事务获取到了锁，那些事务在阻塞中
一致性非阻塞读（consistent nonblocking read）
一致性非阻塞读表示存储引擎通过MVCC方式读取当前时间数据库中的数据，如果正在读取的行正在执行delete或者update操作，读操作被会被阻塞，而是会读取该行记录的快照数据。
在事务隔离级别为READ COMMITTED 和 REPEATABLE READ 下，InnoDB采用非阻塞读方式。但是在READ COMMITTED隔离级别下，读取到的快照数据是最新的一个快照数据(不可重复读)，而在REPEATABLE READ模式下，读取到的快照数据总是在事务开始时读取到的快照数据（可重复读）
REPEATABLE READ隔离级别下，在同一个事务内，读取到的数据总是一致的（因为msyql默认的隔离级别是RR,因此我们使用RR测试）
|
会话A |
会话B |
|---|---|
|
start TRANSACTION; |
|
|
select * from a where id=1;(a1=1) |
|
|
start TRANSACTION; |
|
|
select * from a where id=1; (a1=10) |
|
|
select * from a where id=1;(a1=1) |
|
|
commit; |
|
|
select * from a where id=1;(a1=1) |
|
|
commit; |
|
|
select * from a where id=1;(a1=10) |
在READ COMMITTED 隔离级别下，在事务内总是读取到最新的快照，也就是可以读取到别的事务提交的数据。(需要手动设置隔离级别为RC,同时将列a1的值重置为1)
|
会话A |
会话B |
|---|---|
|
start TRANSACTION; |
|
|
select * from a where id=1;(a1=1) |
|
|
start TRANSACTION; |
|
|
select * from a where id=1; (a1=10) |
|
|
select * from a where id=1;(a1=1) |
|
|
commit; |
|
|
select * from a where id=1;(a1=10) |
|
|
commit; |
|
|
select * from a where id=1;(a1=10) |
一致性阻塞读
行锁的3种算法
Record Lock: 单行记录上的锁，锁住的是索引记录，如果表没有任何创建索引，那么InnoDB默认使用隐式的主键进行锁定
Gap Lock:间隙锁，锁定一个范围，不包含记录本身
Next-Key Lock:Gap+Record Lock,锁定一个范围，包括记录本身
如果采用Next-Key Lock算法，那么针对表a中的列a3(普通索引，值分为为 3,6,12)，那么可能被Next-Key Locking的区间为：
(-∞, 3], (3,6], (6,12], (12,+∞)
采用Next-Key Lock的锁定技术称为Next-Key Locking,目的是为了解决幻读问题(Phantom Problem),除了next-key locking ,还有previous-key locking 技术，如果采用previous-key locking,那么上述a3可锁定的区间为：
(-∞, 3), [3,6), [6,12), [12,+∞)
当查询的索引是唯一索引时，InnoDB会对Next-Key Locking进行优化，降级为Record Lock,值锁住索引本身，而不是范围
以下针对列a2进行测试，a2为唯一索引，a2的值为 2，4，6
在Next-Key Lock算法下，可锁住的区间为(-∞, 2], (2,4], (4,6], (6,+∞)，5和3处于索引范围内，会话B获取5和3的锁应该要等待，但是由于a2是唯一索引，因此降级为Record Lock，仅锁住a2=4本身，所以会话B不会被阻塞
|
会话A |
会话B |
|---|---|
|
start TRANSACTION; |
|
|
select * from a where a2=4 for update; |
|
|
start TRANSACTION; |
|
|
select * from a where a2=5 for update;(成功，不需要等待) |
|
|
select * from a where a2=3 for update;(成功，不需要等待) |
|
|
commit; |
|
|
commit; |
|
看下普通索引在Next-key Lock算法下的情况
使用表a的列a1测试，a1为普通索引
采用Next-Key Lock 算法，可锁定的区间为(-∞, 1), (1,2), (2,3),(3,9), (9,+∞),
|
会话A |
会话B |
|---|---|
|
start TRANSACTION; |
|
|
select * from a where a1=3 for update; |
|
|
start TRANSACTION; |
|
|
select * from a where a1=5 for update;(获取锁不成功，因为5处于(3,9]之间) |
|
|
select * from a where a1=2 for update;(获取锁不成功，因为2处于锁定范围内) |
|
|
select * from a where a1=3 lock in share mode; (获取锁不成功，因为3本身已被锁定) |
|
|
select * from a where id=1 for update;(获取锁不成功) 为什么1会被锁定 |
|
|
select * from a where id=10 for update;(获取锁成功，因为会话A锁定的范围是[1,9),10不在锁定范围内，因此获取锁成功)为什么锁定范围不是(2,9) |
|
|
select * from a where id=0 for update;(获取锁成功) |
死锁
死锁是由于两个或两个以上的事务在执行过程中，因争夺资源而造成的一种相互等待的现象。
解决死锁最简单的方式是不要有等待，将任何的等待转化为回滚。两个事务相互等待，当其中一个等待时间超过设置的某一个阈值，根据权重，将其中一个事务回滚，另外一个事务就可以正常运行。
权重在前面提到过(txr_weight),权重的大小取决于事务修改和锁定的行数，更新的行数越小，占用的undo log 也就越少，回滚需要的时间也就越少
测试下死锁
|
会话A |
会话B |
|---|---|
|
会话A |
会话B |
|
start TRANSACTION; |
|
|
delete from a where id=3; (成功) |
|
|
start TRANSACTION; |
|
|
delete from a where id=2;（成功） |
|
|
delete from a where id=2;（等待） |
|
|
delete from a where id=3; (等待) |
|
|
超时回滚其中一个事务 |
show engine innodb status ; 查看死锁日志
===================================== 2019-07-26 02:02:56 0x70000b18b000 INNODB MONITOR OUTPUT ===================================== Per second averages calculated from the last 15 seconds ----------------- BACKGROUND THREAD ----------------- srv_master_thread loops: 84 srv_active, 0 srv_shutdown, 167877 srv_idle srv_master_thread log flush and writes: 167921 ---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 155 OS WAIT ARRAY INFO: signal count 154 RW-shared spins 0, rounds 270, OS waits 133 RW-excl spins 0, rounds 666, OS waits 6 RW-sx spins 0, rounds 0, OS waits 0 Spin rounds per wait: 270.00 RW-shared, 666.00 RW-excl, 0.00 RW-sx ------------------------ LATEST DETECTED DEADLOCK ------------------------ 2019-07-26 02:02:42 0x70000b037000 *** (1) TRANSACTION: TRANSACTION 53206, ACTIVE 10 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1 MySQL thread id 25, OS thread handle 123145487921152, query id 2377 localhost 127.0.0.1 root updating delete from a where id=3 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 246 page no 3 n bits 80 index PRIMARY of table `hotel_mint`.`a` trx id 53206 lock_mode X locks rec but not gap waiting Record lock, heap no 4 PHYSICAL RECORD: n_fields 6; compact format; info bits 32 0: len 4; hex 80000003; asc ;; 1: len 6; hex 00000000cfd1; asc ;; 2: len 7; hex 220000012822e4; asc " (" ;; 3: len 4; hex 80000003; asc ;; 4: len 4; hex 80000006; asc ;; 5: len 4; hex 8000000c; asc ;; *** (2) TRANSACTION: TRANSACTION 53201, ACTIVE 13 sec starting index read mysql tables in use 1, locked 1 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1 MySQL thread id 23, OS thread handle 123145487085568, query id 2378 localhost 127.0.0.1 root updating delete from a where id=2 *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 246 page no 3 n bits 80 index PRIMARY of table `hotel_mint`.`a` trx id 53201 lock_mode X locks rec but not gap Record lock, heap no 4 PHYSICAL RECORD: n_fields 6; compact format; info bits 32 0: len 4; hex 80000003; asc ;; 1: len 6; hex 00000000cfd1; asc ;; 2: len 7; hex 220000012822e4; asc " (" ;; 3: len 4; hex 80000003; asc ;; 4: len 4; hex 80000006; asc ;; 5: len 4; hex 8000000c; asc ;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 246 page no 3 n bits 80 index PRIMARY of table `hotel_mint`.`a` trx id 53201 lock_mode X locks rec but not gap waiting Record lock, heap no 3 PHYSICAL RECORD: n_fields 6; compact format; info bits 32 0: len 4; hex 80000002; asc ;; 1: len 6; hex 00000000cfd6; asc ;; 2: len 7; hex 250000030f0d82; asc % ;; 3: len 4; hex 80000002; asc ;; 4: len 4; hex 80000004; asc ;; 5: len 4; hex 80000006; asc ;; *** WE ROLL BACK TRANSACTION (2) ------------ TRANSACTIONS ------------ Trx id counter 53212 Purge done for trx's n:o < 53212 undo n:o < 0 state: running but idle History list length 52 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 281479538886448, not started 0 lock struct(s), heap size 1136, 0 row lock(s) ---TRANSACTION 281479538887352, not started 0 lock struct(s), heap size 1136, 0 row lock(s) ---TRANSACTION 53206, ACTIVE 24 sec 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2 MySQL thread id 25, OS thread handle 123145487921152, query id 2380 localhost 127.0.0.1 root -------- FILE I/O -------- I/O thread 0 state: waiting for i/o request (insert buffer thread) I/O thread 1 state: waiting for i/o request (log thread) I/O thread 2 state: waiting for i/o request (read thread) I/O thread 3 state: waiting for i/o request (read thread) I/O thread 4 state: waiting for i/o request (read thread) I/O thread 5 state: waiting for i/o request (read thread) I/O thread 6 state: waiting for i/o request (write thread) I/O thread 7 state: waiting for i/o request (write thread) I/O thread 8 state: waiting for i/o request (write thread) I/O thread 9 state: waiting for i/o request (write thread) Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] , ibuf aio reads:, log i/o's:, sync i/o's: Pending flushes (fsync) log: 0; buffer pool: 0 2182 OS file reads, 1151 OS file writes, 505 OS fsyncs 0.00 reads/s, 0 avg bytes/read, 1.53 writes/s, 0.80 fsyncs/s ------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- Ibuf: size 1, free list len 0, seg size 2, 0 merges merged operations: insert 0, delete mark 0, delete 0 discarded operations: insert 0, delete mark 0, delete 0 Hash table size 34673, node heap has 0 buffer(s) Hash table size 34673, node heap has 0 buffer(s) Hash table size 34673, node heap has 0 buffer(s) Hash table size 34673, node heap has 0 buffer(s) Hash table size 34673, node heap has 1 buffer(s) Hash table size 34673, node heap has 0 buffer(s) Hash table size 34673, node heap has 0 buffer(s) Hash table size 34673, node heap has 0 buffer(s) 1.53 hash searches/s, 1.13 non-hash searches/s --- LOG --- Log sequence number 3022251932 Log flushed up to 3022251932 Pages flushed up to 3022251932 Last checkpoint at 3022251923 0 pending log flushes, 0 pending chkp writes 306 log i/o's done, 0.47 log i/o's/second ---------------------- BUFFER POOL AND MEMORY ---------------------- Total large memory allocated 137428992 Dictionary memory allocated 439113 Buffer pool size 8191 Free buffers 5999 Database pages 2191 Old database pages 818 Modified db pages 0 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages made young 0, not young 0 0.00 youngs/s, 0.00 non-youngs/s Pages read 2109, created 82, written 769 0.00 reads/s, 0.07 creates/s, 1.00 writes/s Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000 Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len: 2191, unzip_LRU len: 0 I/O sum[0]:cur[0], unzip sum[0]:cur[0] -------------- ROW OPERATIONS -------------- 0 queries inside InnoDB, 0 queries in queue 0 read views open inside InnoDB Process ID=103, Main thread ID=123145481420800, state: sleeping Number of rows inserted 5879, updated 11, deleted 11, read 798826 0.00 inserts/s, 0.00 updates/s, 0.07 deletes/s, 0.07 reads/s ---------------------------- END OF INNODB MONITOR OUTPUT ============================
避免死锁的方法
1、系统中事务的数量尽量少
2、避免大事务，事务尽量小
3、避免大sql,能拆则拆，避免长时间占用资源，导致其他事务等待或者与其他事务冲突发生死锁