同乐学堂2.6 其他锁问题
一些可能影响应用程序的因素包括内部锁和服务器在运行特定操作时的一些互斥请求。不过大多数时候它们保证了数据的完整性。不过有一些异常，比如InnoDB互斥和循环锁，你不能也不应该尝试控制它们，不过由于它们中的一部分可能会对用户应用程序可见，因此这里将介绍它们。事务可能会产生争用情形和导致死锁，当然也可以产生其他情况。当MySQL服务器开始使用如文件等资源，或者修改线程间共享的变量的时候，它会锁住资源以避免其他线程对同一个资源的并发访问。这解决了数据一致性的问题。不过同时，这种保护又会带来死锁。这种死锁很难诊断并且从理论上应该不会反生，不过由于它们在过去确实出现过，因此这里将会介绍当你怀疑是这种情况的时候应该做什么。作为示例，我将会用来自bug报告上的一个测试用例来创造一个死锁。该bug与排除元数据锁（MDL）中的故障无关，因此我将仅关注调试本身，而不介绍产生死锁的行为。 提示看起来这似乎是通过人为构造的手段去解释MySQL的bug导致的问题，而不是来自用户的错误，不过该消息还是很有用的。你不能保证不再遇到bug，因此做好准备是必要的。所谓有备无患。“资源”死锁的典型特征与行锁导致的死锁的特征一致：就是查询被挂起。没有内部机制可以发现并终止这类死锁，因此不要指望线程会超时（像InnoDB锁那样）或者会立即回滚（像InnoDB死锁那样）。
SHOW PROCESSLIST命令会输出如下信息。
该输出表明有很多查询等待不同类型的锁超过了9000秒。SHOW ENGINE INNODB STATUS命令的TRANSACTIONS部分也没有给出任何新的信息：
从5.5版本开始，可以通过performance_schema来获取额外的信息，这将在2.8.4节进行介绍。这里想介绍当我刚刚提到的问题出现时该怎么做。首先应该检查的表是MUTEX_INSTANCE，该表会列出自服务器启动以来所有的冲突。其中一部分现在没有使用，所以你应该在SELECT查询中略过它们，仅获取LOCKED_BY_THREAD_ID不为空的那些记录。
要找出谁在等待这些冲突，可以查询EVENTS_WAITS_CURRENT表：
输出中的THREAD_ID，是内部mysqld分配给线程的实际编号，而不是帮助找到产生死锁原因的连接线程的编号。为了找到连接线程的编号，可以查询THREADS表。这里没有过滤输出，因为我想给你展示在mysqld进程内，当给该示例提供6个连接服务时所有运行的线程。
既然我们在没有借助任何其他操作的情况下（例如，如给正在运行的mysqld进程挂接调试器），获取了服务器内所有运行状况的信息。在这个示例中，我们实际在上第一次运行SHOW PROCESSLIST命令后就获取了我们需要的所有信息。不过，我想展示当跟当前示例中一样状态信息不是很明确时，通过performance_schema表可以给调试内部死锁等问题带来何种帮助。解决死锁问题应该做什么？你需要选择一个连接作为牺牲品，然后终止它。在这种情况下，幸运的话，我们会通过SHOW ENGINE INNODB STATUS命令发现一个相对不重要的连接。
下面是关于MySQL服务器的线程10的描述：
该线程没有等待任何操作，却锁住了两个表。下面终止它：
我们很幸运，通过仅终止这个单独的连接解决了问题：
以上是关于系统死锁的简介以及当你遭遇死锁的时候该做什么。基本的程序就是确认有线程确实在一直等待，然后找到一个不是必需的线程并终止它。你不用担心终止一个缓慢的线程，因为终止它们然后手动修复任何造成的错误，比无限期地等待直到mysqld由于其他原因停止要好得多。
你可能会在应用程序中遭遇其他影响服务器内部锁的情况。有一些甚至会导致服务崩溃。例如，InnoDB出于各种锁定目的使用一些信号标志，如为了保护CHECK TABLE和OPTIMIZE TABLE，但是如果InnoDB信号量等待超过600秒，InnoDB会故意使服务器崩溃。
警告
不要把信号量的长等待时间和持续多于600秒的用户会话混为一谈。InnoDB的信号量用于保护特定的操作。而单个会话可以完全不影响或者影响其中的大部分。可以监控应用程序的状态从而避免这种情况。因此，存储引擎在其监控器中也会输出关于InnoDB的信号量的等待时间的信息：
提示
不用担心InnoDB输出需要等待操作的信号量需要花费很长的时间，如在一个大表上的CHECK TABLE操作。你需要解决的是在常规操作中长时间等待的情形。
微信扫一扫，打赏作者吧～
