web-dev-qa-db-ja.com

テーブルレベルのロックをトリガーする条件

いくつかの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

通常、ロックの問題を診断するためのパターンは、どのクエリがロックされていないかを特定することであり、一般的には原因があります。ただし、この場合、関連のないテーブルを読み取っていて、最も長く実行されているクエリ（これは、唯一の更新クエリであるため、確かに問題の一部です）もロックされます。

つまり、ここで見られるような状況から予想される、テーブルレベルのロックが適用される原因となる追加の条件は何かということです。

追加の詳細
これは標準のmysqlインストールに関するものです。パーティショニングやその他のシェナニガンは含まれていません
テーブルpostsはタイプMyISAMです
テーブルsessionはタイプMEMORYです
その他の問題（クエリ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'
linuxmysqlperformancemyisam
2
tylerl

ロック時にmysqldumpが実行されていますか？スレッド83が現在postをエクスポートしているように見えますが、すべてのテーブルで一貫した位置を取得するためにDBでLOCK TABLESを呼び出している可能性があります。

2
smin