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