<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: How to find out who is locking a table  in MySQL</title>
	<atom:link href="http://www.xaprb.com/blog/2006/07/31/how-to-analyze-innodb-mysql-locks/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.xaprb.com/blog/2006/07/31/how-to-analyze-innodb-mysql-locks/</link>
	<description>Stay curious!</description>
	<lastBuildDate>Thu, 09 Feb 2012 09:56:43 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Doru</title>
		<link>http://www.xaprb.com/blog/2006/07/31/how-to-analyze-innodb-mysql-locks/#comment-19448</link>
		<dc:creator>Doru</dc:creator>
		<pubDate>Thu, 23 Jun 2011 19:10:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/?p=158#comment-19448</guid>
		<description>To see which MYISAM tables are locked try &#039;show open tables&#039; 

See this article: http://stackoverflow.com/questions/2499976/detecting-locked-tables-mysql-locked-by-lock-table
and the manual: http://dev.mysql.com/doc/refman/5.0/en/show-open-tables.html</description>
		<content:encoded><![CDATA[<p>To see which MYISAM tables are locked try &#8216;show open tables&#8217; </p>
<p>See this article: <a href="http://stackoverflow.com/questions/2499976/detecting-locked-tables-mysql-locked-by-lock-table" rel="nofollow">http://stackoverflow.com/questions/2499976/detecting-locked-tables-mysql-locked-by-lock-table</a><br />
and the manual: <a href="http://dev.mysql.com/doc/refman/5.0/en/show-open-tables.html" rel="nofollow">http://dev.mysql.com/doc/refman/5.0/en/show-open-tables.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: APZ</title>
		<link>http://www.xaprb.com/blog/2006/07/31/how-to-analyze-innodb-mysql-locks/#comment-17938</link>
		<dc:creator>APZ</dc:creator>
		<pubDate>Thu, 04 Mar 2010 16:42:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/?p=158#comment-17938</guid>
		<description>Hi,

Nice article!

Do you have any tips for diagnosing deadlocks where there appears to be only one active process?</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>Nice article!</p>
<p>Do you have any tips for diagnosing deadlocks where there appears to be only one active process?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Levi</title>
		<link>http://www.xaprb.com/blog/2006/07/31/how-to-analyze-innodb-mysql-locks/#comment-1397</link>
		<dc:creator>Levi</dc:creator>
		<pubDate>Tue, 08 Aug 2006 23:44:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/?p=158#comment-1397</guid>
		<description>&lt;p&gt;SHOW PROCESSLIST; also helps a lot.&lt;/p&gt;

&lt;p&gt;In particular, itâ€™s the only way Iâ€™ve found to identify MyISAM implicit locks: MyISAM doesnâ€™t support transactions, and prioritises updates over reads. To avoid inconsistent data, reads can cause implicit table locks.&lt;/p&gt;

&lt;p&gt;Where this matters is a situation like the following:&lt;/p&gt;

&lt;pre&gt;SELECT * from bigTable WHERE (complicatedQueryConditions);
UPDATE bigTable SET someField=someField+1 WHERE id=1;&lt;/pre&gt;

&lt;p&gt;The SELECT will lock out the UPDATE until it finishes, and because updates are prioritised over reads and new selects will in turn be waiting for the UPDATE to finish.&lt;/p&gt;

&lt;p&gt;If the SELECT takes eg 30 seconds, in effect every access to that table will be waiting on the SELECT. In such a situation, SHOW PROCESSLIST will be able to show you which query is not in a LOCKED state, and you can identify the evil query quite quickly.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>SHOW PROCESSLIST; also helps a lot.</p>
<p>In particular, itâ€™s the only way Iâ€™ve found to identify MyISAM implicit locks: MyISAM doesnâ€™t support transactions, and prioritises updates over reads. To avoid inconsistent data, reads can cause implicit table locks.</p>
<p>Where this matters is a situation like the following:</p>
<pre>SELECT * from bigTable WHERE (complicatedQueryConditions);
UPDATE bigTable SET someField=someField+1 WHERE id=1;</pre>
<p>The SELECT will lock out the UPDATE until it finishes, and because updates are prioritised over reads and new selects will in turn be waiting for the UPDATE to finish.</p>
<p>If the SELECT takes eg 30 seconds, in effect every access to that table will be waiting on the SELECT. In such a situation, SHOW PROCESSLIST will be able to show you which query is not in a LOCKED state, and you can identify the evil query quite quickly.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

