Ideas, releases, practical guides, and perspectives from the people building with MySQL.
This recent session at OSDC 2011 Canberra is based on part of an Open Query training day, and (due to time constraints) without much of the usual interactivity, exercises and further MySQL specific detail. People liked it anyway, which is nice! The info as presented is not MySQL specific, it provides general insight in how databases implement concurrency and what trade-offs they make.
See http://2011.osdc.com.au/SQLL for the talk abstract.
Vadim and others have pointed at the index->lock problems before, but I think they didn’t good job enough at pointing out how bad it can get (the actual problematic was hidden somewhere as some odd edge case). What ‘index lock’ means is generally the fact that InnoDB has table-level locking which will kill performance on big tables miserably.
InnoDB is a huge pie of layers, that have various locking behaviors, and are layered on top of each other, and are structured nicely as subdirectories in your innodb_plugin directory. Low level storage interfaces are done via os/ routines, then on top of that there’s some file space manager, fsp/, which allocates space for btr/ to live in, where individual page/ entities live, with multiple row/ pieces. There’re few other subsystems around, that got …
[Read more]This is another article in a series of articles titled "A few notes ..." in which I will be posting some important information about locking concepts, different types of locks and what locks table engines support. Just like the previous article, the purpose of this article is to highlight important aspects that you should have in the back of your mind when developing applications.
Isolation is an important part of ACID properties that guarantee that transactions are processed in a reliable manner. But there are four different levels of isolation available and you have to understand each one of them to be able to select the correct one for your needs. This post intends on explaining the four levels together with their effects on locking and performance.
Although MyISAM has been the default storage engine for MySQL but its soon going to change with the release of MySQL server 5.5. Not only that, more and more people are shifting over to the Innodb storage engine and the reasons for that is the tremendous benefits, not only in terms of performance, concurrency, ACID-transactions, foreign key constraints, but also because of the way it helps out the DBA with hot-backups support, automatic crash recovery and avoiding data inconsistencies which can prove to be a pain with MyISAM. In this article I try to hammer out the reasons why you should move on to using Innodb instead of MyISAM.
Well, it took us a little while (we’ve been busy !), but we’ve now posted our presentations on InnoDB from the MySQL Conference and Expo 2009. You can download these presentations by Heikki Tuuri, Ken Jacobs and Calvin Sun from the InnoDB website, as follows:
MySQL University sessions are starting again after the winter break. This Thursday, we're beginning with Tim Cook's presentation on low-level locking in mysqld and InnoDB – the good, the bad, and the ugly. Tim works in the Performance and Applications Engineering department at Sun Microsystems. Expect to get some deep insights into the inner workings of the MySQL Server and InnoDB.
Tim's based in California, so note that his session will start rather late for Europeans.
For MySQL University sessions, point your browser to this page. You need a browser with a working Flash plugin. You may …
[Read more]MySQL uses locks for concurrency control. Whenever a client/thread acquires a lock, it will have exclusive access to that table or row (depending on the granularity of the lock). Other clients however, will be prevented from writing and possibly reading to/from the locked resource. The two main existing locks are:
READ LOCK – A read lock will allow the other
clients to read from the locked resource but not write to
it.
WRITE LOCK – a write lock will prevent the other
clients from reading or writing to the locked resource.
Also, different storage engines have different lock granularity. For example, MyISAM will lock the whole table while InnoDB will only lock the rows it needs.
Let’s try this out using a MyISAM table. We open two concurrent sessions and in the first lock the City table from the world database (get it …
[Read more]
A high-performance application that has producers and consumers
of some resource, such as a queue of messages, needs an efficient
way to notify the consumers when the producer has inserted into
the queue. Polling the queue for changes is not a good option.
MySQL's GET_LOCK() and RELEASE_LOCK()
functions can provide both mutual exclusivity and notifications.
This post was prompted by a message to the MySQL general emailing list some time ago, but I'm finally getting around to actually testing the theoretical solution I mentioned then. I can never just think my way through anything that involves locking and waiting... I have to test it.