Comments on: How to give locking hints in MySQL http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/ Stay curious! Fri, 16 May 2008 04:23:04 +0000 http://wordpress.org/?v=2.2.2 By: Xaprb http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1371 Xaprb Mon, 07 Aug 2006 20:17:59 +0000 http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1371 <p>See Peter's comment and article -- as he points out, an ordinary <code>SELECT</code> doesn't lock any rows. Also, see the section of the MySQL manual dealing with <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-consistent-read.html">consistent non-locking read</a>. I suspect something else was causing the main query for the page to take so long.</p> See Peter’s comment and article — as he points out, an ordinary SELECT doesn’t lock any rows. Also, see the section of the MySQL manual dealing with consistent non-locking read. I suspect something else was causing the main query for the page to take so long.

]]> By: Chris http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1369 Chris Mon, 07 Aug 2006 18:37:19 +0000 http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1369 <p>We encountered performance problems when we attempted to use READ UNCOMMITTED on the master database for our web site.</p> <p>Our master database has a load of lots of short queries (about 1000 reads and 250 writes per second). Our few long queries on this database take at most 5 seconds. We are running MySQL 4.1.</p> <p>For one web page we wanted to not acquire read locks because the main SELECT for the page was known to occasionally run for several seconds, the table got a lot of writes, and there were no application level consistency requirements between rows. We used the following SQL to set this up:</p> <pre>SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED</pre> <p>What we later discovered was that this SQL statement sometimes took several seconds to execute. We removed this SQL statement and observed that overall load on our master database dropped substantially.</p> <p>We don't know why this happened, but we're now avoiding READ UNCOMMITTED. Interested in any insight as to why this would be slow, whether this is most likely user error on our part, and any other real world benchmarking of the locking statements.</p> <p>Thanks!</p> We encountered performance problems when we attempted to use READ UNCOMMITTED on the master database for our web site.

Our master database has a load of lots of short queries (about 1000 reads and 250 writes per second). Our few long queries on this database take at most 5 seconds. We are running MySQL 4.1.

For one web page we wanted to not acquire read locks because the main SELECT for the page was known to occasionally run for several seconds, the table got a lot of writes, and there were no application level consistency requirements between rows. We used the following SQL to set this up:

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

What we later discovered was that this SQL statement sometimes took several seconds to execute. We removed this SQL statement and observed that overall load on our master database dropped substantially.

We don’t know why this happened, but we’re now avoiding READ UNCOMMITTED. Interested in any insight as to why this would be slow, whether this is most likely user error on our part, and any other real world benchmarking of the locking statements.

Thanks!

]]> By: Xaprb http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1356 Xaprb Sun, 06 Aug 2006 21:56:49 +0000 http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1356 <p>Yes, as far as I recall SQL Server 2000 does NOT do multi-versioning at all; everything is simply controlled through locks. However, I also think I learned at the SQL Server 2005 training I attended (which I have now forgotten) that 2005 does do multi-versioning if you select the right transaction isolation level. So there may be a more valid comparison between 2005 and InnoDB, but it's a good point that multi-versioning and locking are not the same thing.</p> Yes, as far as I recall SQL Server 2000 does NOT do multi-versioning at all; everything is simply controlled through locks. However, I also think I learned at the SQL Server 2005 training I attended (which I have now forgotten) that 2005 does do multi-versioning if you select the right transaction isolation level. So there may be a more valid comparison between 2005 and InnoDB, but it’s a good point that multi-versioning and locking are not the same thing.

]]> By: MySQL Performance Blog » SELECT LOCK IN SHARE MODE and FOR UPDATE http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1355 MySQL Performance Blog » SELECT LOCK IN SHARE MODE and FOR UPDATE Sun, 06 Aug 2006 21:01:39 +0000 http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1355 <p>[...] Baron wrote nice article comparing locking hints in MySQL and SQL Server. [...]</p> […] Baron wrote nice article comparing locking hints in MySQL and SQL Server. […]

]]> By: Peter http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1354 Peter Sun, 06 Aug 2006 20:19:29 +0000 http://www.xaprb.com/blog/2006/08/05/how-to-give-locking-hints-in-mysql/#comment-1354 <p>Baron,</p> <p>I would not however call MySQL modifiers "hints" as they actually result in different behavior.</p> <p>Select for Innodb does not set any locks by default and multi versioning is used. </p> <p>For LOCK IN SHARE MODE or FOR UPDATE modifiers not only locks will be set but versioning will effectively be bypass versioning. </p> <p>Yes if you plan updating a lot it makes sense to use SELECT FOR UPDATE.</p> Baron,

I would not however call MySQL modifiers “hints” as they actually result in different behavior.

Select for Innodb does not set any locks by default and multi versioning is used.

For LOCK IN SHARE MODE or FOR UPDATE modifiers not only locks will be set but versioning will effectively be bypass versioning.

Yes if you plan updating a lot it makes sense to use SELECT FOR UPDATE.

]]>