第一步：查看锁表情况
执行如下指令：
show status like 'Table%'
核心指标说明：
Table_locks_immediate： 指的是能够立即获得表级锁的次数
Table_locks_waited： 指的是不能立即获取表级锁而需要等待的次数，如果数量大，说明锁等待多，有锁争用情况
第二步：正在被锁定的的表
执行如下指令：
show open TABLES where In_use > 0;
第三步：如果查看到锁争用情况严重，可以再查看当前执行的SQL
执行如下指令：
show processlist;
如果需要过滤用户/db/commond 等相关信息，也可以使用information_schema.processlist 表信息。
指令如下：
select * from information_schema.processlist;
也可以通过mysqladmin 指令打印processlist 进程信息。
执行如下指令:
root@241448b9f8d6:/# mysqladmin -uroot -p processlist
Enter password:
+----+-----------------+------------------+-------+---------+------+------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+------------------+-------+---------+------+------------------------+------------------+
| 5 | event_scheduler | localhost | | Daemon | 8776 | Waiting on empty queue | |
| 55 | root | 172.17.0.1:56330 | house | Sleep | 1992 | | |
| 56 | root | 172.17.0.1:56332 | house | Sleep | 234 | | |
| 57 | root | 172.17.0.1:56334 | house | Sleep | 234 | | |
| 58 | root | localhost | | Query | 0 | init | show processlist |
+----+-----------------+------------------+-------+---------+------+------------------------+------------------+
mysqladmin命令有一个debug参数，可以分析当前MySQL服务的状态信息，同时也可以用来帮助我们定位当前锁的详细情况，这里我们通过该命令分析一下当前MySQL服务的详细状态，执行mysqladmin命令如下：
root@241448b9f8d6:/etc/mysql# mysqladmin -ujss -p -S /var/run/mysqld/mysqld.sock debug
Enter password:拓展：
/var/run/mysqld/mysqld.sock: MySQL的配置文件my.cnf 查看Socker 文件目录地址
温馨提示： debug会将状态信息生成到mysql的错误文件，一般锁的信息都会保存在最后几行。
表锁文件展示:
hread database.table_name Locked/Waiting Lock_type
2 hdpic.t_wiki_zutu Waiting - write Highest priority write lock
123890 hdpic.t_wiki_zutu_category Locked - read Low priority read lock
123890 hdpic.t_wiki_zutu_photo Locked - read Low priority read lock
123890 hdpic.t_wiki_zutu Locked - read Low priority read lock
124906 hdpic.t_wiki_zutu Waiting - read Low priority read lock从上述信息可以看出，123890持有的读锁阻塞了2的写入和124906的读操作，这个状态符合我们的推论，接下来处理就比较单纯了，如果现状不可接受，不能继续等待，将123890杀掉，释放资源即可：
执行如下指令:
mysql> kill 123890;
Query OK, 0 rows affected (0.00 sec)