Mysql Lock times in slow query log

Question

I have an application that has been running fine for quite awhile, but recently a couple of items have started popping up in the slow query log. All the queries are complex and ugly multi join select statements that could use refactoring. I believe all of them have blobs, meaning they get written to disk. The part that gets me curious is why some of them have a lock time associated with them. None of the queries have any specific locking protocols set by the application. As far as I know, by default you can read against locks unless explicitly specified.

so my question: What scenarios would cause a select statement to have to wait for a lock (and thereby be reported in the slow query log)? Assume both INNODB and MYISAM environments.

Could the disk interaction be listed as some sort of lock time? If yes, is there documentation around that says this?

thanks in advance.

Answer 1

MyISAM will give you concurrency problems, an entire table is completely locked when an insert is in progress.

InnoDB should have no problems with reads, even while a write/transaction is in progress due to it's MVCC.

However, just because a query is showing up in the slow-query log doesn't mean the query is slow - how many seconds, how many records are being examined?

Put "EXPLAIN" in front of the query to get a breakdown of the examinations going on for the query.

here's a good resource for learning about EXPLAIN (outside of the excellent MySQL documentation about it)

Answer 2

I'm not certain about MySql, but I know that in SQL Server select statements do NOT read against locks. Doing so will allow you to read uncommitted data, and potentially see duplicate records or miss a record entirely. The reason for this is because if another process is writing to the table, the database engine may decide it's time to reorganize some data and shifts it around on disk. So it moves a record you already read to the end and you see it again, or it moves one from the end up higher where you've already past.

There's a guy on the net somewhere who actually wrote a couple of scripts to prove that this happens and I tried them once and it only took a few seconds before a duplicate showed up. Of course, he designed the scripts in a fashion that would make it more likely to happen, but it proves that it definitely can happen.

This is okay behaviour if your data doesn't need to be accurate and can certainly help prevent deadlocks. However, if you're working on an application dealing with something like people's money then that's very bad.

In SQL Server you can use the WITH NOLOCK hint to tell your select statement to ignore locks. I'm not sure what the equivalent in MySql would be but maybe someone else here will say.