mysql读写锁状态分析

表锁：

命令：show status like 'table%';

 

Table_locks_immediate:产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1

Table_locks_waited:出现表级锁定争用而发生等待的次数（不能立即获取锁的次数，每等待一次锁值加1），此值高则说明存在着较严重的表级锁争用情况；

 表锁偏向于MYISAM引擎

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

 ***************************************************************************************************************************************

查看数据库的隔离级别

show variables like 'tx_isolation';

 

行锁：

 

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

*****************************************************************************************************************************************

应该尽量避免：

索引失效的时候，行锁变为表锁

间隙锁的产生

【什么是间隙锁】
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键
值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，
InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。
【危害】
因为Query执行过程中通过过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个_值并不存在。
间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无
法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害

 

 

****************************************************************************************************************

行锁总结

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　　　　　　　　 --系统启动后到现在总共等待的次数