处理一些vBulletin性能问题，我遇到了这种情况，一切都卡在等级的表级锁：
Id Command Time State Info 83 Query 47 Writing to net SELECT /*!40001 SQL_NO_CACHE */ * FROM `post` 87 Query 117 Waiting for table level lock UPDATE session SET lastactivity = 1362132185, location = '/for 89 Query 116 Waiting for table level lock SELECT * FROM session WHERE userid = 0 AND host = '178.1 90 Query 113 Waiting for table level lock SELECT * FROM session WHERE userid = 0 AND host = '66.24 94 Query 108 Waiting for table level lock select userid from session where sessionhash = '2269de072969ab9d42 96 Query 102 Waiting for table level lock SELECT * FROM session WHERE sessionhash = 'b0e3d290e9f609160 129 Query 15 Waiting for table level lock SELECT * FROM session WHERE userid = 0 AND host = '65.55 130 Query 14 Waiting for table level lock SELECT * FROM session WHERE userid = 0 AND host = '71.19 132 Query 13 Waiting for table level lock SELECT * FROM session WHERE userid = 0 AND host = '178.1 通常情况下，诊断locking问题的模式是找出哪个查询没有被locking，并且通常有你的罪魁祸首。 但在这种情况下，它正在读取一个不相关的表，并且运行时间最长的查询（这肯定是问题的一部分，因为它是唯一的更新查询）也被locking。
所以问题是，什么额外的条件可以导致一个表级locking应用，你可能期望从这里看到的情况。
添加详细信息
这是关于一个标准的MySQL安装; 没有涉及分区或其他shenanigans
表格posts是typesMyISAM
表session是types记忆
其他问题（例如查询83显然效率低下或者使用MyISAM的不合适性）是有趣的，但不是所要求的。
查询87的全文如下所示：
Query UPDATE session SET lastactivity = 1362132185, location = '/forums/forumdisplay.php?f=421', inforum = 421, inthread = 0, incalendar = 0, badlocation = 0 WHERE sessionhash = 'e6322935fe2df18106878473f310d91f'
mysqldump是否在locking时运行？ 看起来像线程83可能正在导出post但可能已经调用数据库上的LOCK TABLES ，以获得在所有表上的一致的立场。