13518219792
-- 查询是否锁表
创新互联专注于库尔勒企业网站建设,响应式网站设计,成都做商城网站。库尔勒网站建设公司,为库尔勒等地区提供建站服务。全流程按需求定制网站，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务
show OPEN TABLES ;
-- 查询进程
show processlist ;
-- 查询到相对应的进程，然后杀死进程
kill id; -- 一般到这一步就解锁了
-- 查看正在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
-- 查看等待锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
-- 解锁表
UNLOCK TABLES;
行锁的等待
在介绍如何解决行锁等待问题前，先简单介绍下这类问题产生的原因。产生原因简述：当多个事务同时去操作（增删改）某一行数据的时候，MySQL 为了维护 ACID 特性，就会用锁的形式来防止多个事务同时操作某一行数据，避免数据不一致。只有分配到行锁的事务才有权力操作该数据行，直到该事务结束，才释放行锁，而其他没有分配到行锁的事务就会产生行锁等待。如果等待时间超过了配置值（也就是 innodb_lock_wait_timeout 参数的值，个人习惯配置成 5s，MySQL 官方默认为 50s），则会抛出行锁等待超时错误。
如上图所示，事务 A 与事务 B 同时会去 Insert 一条主键值为 1 的数据，由于事务 A 首先获取了主键值为 1 的行锁，导致事务 B 因无法获取行锁而产生等待，等到事务 A 提交后，事务 B 才获取该行锁，完成提交。这里强调的是行锁的概念，虽然事务 B 重复插入了主键，但是在获取行锁之前，事务一直是处于行锁等待的状态，只有获取行锁后，才会报主键冲突的错误。当然这种 Insert 行锁冲突的问题比较少见，只有在大量并发插入场景下才会出现，项目上真正常见的是 updatedelete 之间行锁等待，这里只是用于示例，原理都是相同的。
三、产生的原因根据我之前接触到的此类问题，大致可以分为以下几种原因
项目坑有千千万，我们静下心来还是可以找到解决办法的
最近接了一个由供应商留下来的项目，正是周末休息时间突然一个电话说功能用不了，翻看日志发现是业务功能的表被锁了，我就奇了怪了，天天没事，突然周末来使儿。一番了解才发现那个锁表情况是天天都有的，但是一直没找到原因，所以DBA运维同事天天充当定时删除机器，每天早上清除锁表进程，丢失的数据也手动补录，厉害了，这就是供应商做的项目吗？烂到这个层度（吐槽一番）
回到正题，我们来聊一聊我的解决步骤
有时候，会很不小心，在业务运行中执行了一条锁表语句。这时候该怎么办？
例如：修改元数据。
SHOW FULL PROCESSLIST 查看一下：
发现修改之后，锁表了。这时候怎么办？ 杀死它 KILL 4623660
然后一切又恢复正常了。
一般对于数据量较大的表，需要修改表结构，或者做一些耗时比较久的锁表操作，建议在晚上（业务闲时）执行。这个时候可以配合使用任务处理一下。
如：修改一个表的字段长度，和添加索引
名词解释：
接着回家睡觉，第二天回来检查结果就好了。
附：添加唯一索引示例
MYSQL存储过程结合任务处理耗时操作
如果你关闭数据库，就可以保证服务器和myisamchk和isamchk之间没有交互作用。但是停止服务器的运行并不是一个好注意，因为这样做会使得没有故障的数据库和表也不可用。本节主要讨论的过程，是避免服务器和myisamchk或isamchk之间的交互作用。实现这种功能的方法是对表进行锁定。服务器由两种表的锁定方法：1.内部锁定内部锁定可以避免客户机的请求相互干扰——例如，避免客户机的SELECT查询被另一个客户机的UPDATE查询所干扰。也可以利用内部锁定机制防止服务器在利用myisamchk或isamchk检查或修复表时对表的访问。语法：锁定表：LOCK TABLES tbl_name {READ | WRITE},[ tbl_name {READ | WRITE},…]解锁表：UNLOCK TABLESLOCK TABLES为当前线程锁定表。UNLOCK TABLES释放被当前线程持有的任何锁。当线程发出另外一个LOCK TABLES时，或当服务器的连接被关闭时，当前线程锁定的所有表自动被解锁。 如果一个线程获得在一个表上的一个READ锁，该线程(和所有其他线程)只能从表中读。如果一个线程获得一个表上的一个WRITE锁，那么只有持锁的线程READ或WRITE表，其他线程被阻止。每个线程等待(没有超时)直到它获得它请求的所有锁。 WRITE锁通常比READ锁有更高的优先级，以确保更改尽快被处理。这意味着，如果一个线程获得READ锁，并且然后另外一个线程请求一个WRITE锁, 随后的READ锁请求将等待直到WRITE线程得到了锁并且释放了它。显然对于检查，你只需要获得读锁。再者钟情跨下，只能读取表，但不能修改它，因此他也允许其它客户机读取表。对于修复，你必须获得些所以防止任何客户机在你对表进行操作时修改它。2.外部锁定服务器还可以使用外部锁定（文件级锁）来防止其它程序在服务器使用表时修改文件。通常，在表的检查操作中服务器将外部锁定与myisamchk或isamchk作合使用。但是，外部锁定在某些系统中是禁用的，因为他不能可靠的进行工作。对运行myisamchk或isamchk所选择的过程取决于服务器是否能使用外部锁定。如果不使用，则必修使用内部锁定协议。 如果服务器用--skip-locking选项运行，则外部锁定禁用。该选项在某些系统中是缺省的，如Linux。可以通过运行mysqladmin variables命令确定服务器是否能够使用外部锁定。检查skip_locking变量的值并按以下方法进行：◆ 如果skip_locking为off，则外部锁定有效您可以继续并运行人和一个实用程序来检查表。服务器和实用程序将合作对表进行访问。但是，运行任何一个实用程序之前，应该使用mysqladmin flush-tables。为了修复表，应该使用表的修复锁定协议。◆ 如果skip_locaking为on，则禁用外部锁定，所以在myisamchk或isamchk检查修复表示服务器并不知道，最好关闭服务器。如果坚持是服务器保持开启状态，月确保在您使用此表示没有客户机来访问它。必须使用卡党的锁定协议告诉服务器是该表不被其他客户机访问。检查表的锁定协议本节只介绍如果使用表的内部锁定。对于检查表的锁定协议，此过程只针对表的检查，不针对表的修复。1.调用mysql发布下列语句：$mysql –u root –p db_namemysqlLOCK TABLE tbl_name READ;mysqlFLUSH TABLES; 该锁防止其它客户机在检查时写入该表和修改该表。FLUSH语句导致服务器关闭表的文件，它将刷新仍在告诉缓存中的任何为写入的改变。2.执行检查过程$myisamchk tbl_name$ isamchk tbl_name 3.释放表锁mysqlUNLOCK TABLES; 如果myisamchk或isamchk指出发现该表的问题，将需要执行表的修复。修复表的锁定协议这里只介绍如果使用表的内部锁定。修复表的锁定过程类似于检查表的锁定过程，但有两个区别。第一，你必须得到写锁而非读锁。由于你需要修改表，因此根本不允许客户机对其进行访问。第二，必须在执行修复之后发布FLUSH TABLE语句，因为myisamchk和isamchk建立的新的索引文件，除非再次刷新改表的高速缓存，否则服务器不会注意到这个改变。本例同样适合优化表的过程。1.调用mysql发布下列语句：$mysql –u root –p db_namemysqlLOCK TABLE tbl_name WRITE;mysqlFLUSH TABLES; 2.做数据表的拷贝，然后运行myisamchk和isamchk：$cp tbl_name.* /some/other/dir$myisamchk --recover tbl_name$ isamchk --recover tbl_name --recover选项只是针对安装而设置的。这些特殊选项的选择将取决与你执行修复的类型。
对于写锁定如下：
1）、如果表没有加锁，那么对其加写锁定。
2）、否则，那么把请求放入写锁队列中。
对于读锁定如下：
1）、如果表没有加写锁，那么加一个读锁。
2）、否则，那么把请求放到读锁队列中。
当然我们可以分别用low_priority 以及high_priority在写和读操作上来改变这些行为。
