MySQL Transaction Timing

Question

I've got some experience using PHP and MySQL, and I know about Transactions but have fairly little experience using them.

I am developing a web application where users will be making/doing various CRUD operations on/to a single DB. (Yes it's InnoDB). And I'm curious as to how transactions will behave, I'll give you a fairly trivial example:

1.) User 1 begins a transaction to update the name of John Smith in my DB to Johnathon Smith.

2.) User 2 begins a transaction to read the name of John Smith right after User 1's transaction has begun, but before it has COMMITTED.

What will User 2 see as the result? John or Johnathon?

During User 1's transaction, is the record of John Smith locked, or can it be read during the transaction?

Also, how does the timing work with these two transactions? Does the transaction of User 2, sit around in some queue and wait until User 1's transaction has completely finished? How does the MySQL DB triage multiple transactions trying to access the same table/record?

Another also, let's say that the operations of User 1's transaction on average take 500 ms to complete, and the operations of User 2's transaction takes on average 750 ms to complete. How long of response time will User 2 have? 1250 ms?

Any links to relevant articles or other SO questions are greatly appreciated!

score 2 · Accepted Answer · edited May 23 '17 at 12:20

The default way it works is that User 2 sees John Smith until User 1 commits and User 2 starts a new transaction.

Stated another way, the default transaction isolation is called REPEATABLE-READ. That is, InnoDB assumes that User 2 wants to see the database as it was when User 2 started his current transaction. Even if other people update data and commit their updates, User 2 still wants to see the original data until he explicitly refreshes his "view" of the database.

The way MySQL solves this is to keep both versions of the updated row around. The "current" version with Johnathon Smith has an internal pointer to the previous version of the row. InnoDB will check these versions, figure out if User 2 should be able to see the current version, and if not, follow the pointer to the previous version. This is done automatically on a row-by-row basis.

There is no reason for User 2's transaction to wait at all, and this is what is meant by "readers don't block writers and vice versa." This is the benefit of the multi-versioning concurrency control (MVCC) feature, which has similar implementations in quite a few RDBMS products, like Oracle, PostgreSQL, and Firebird.

Once User 1 commits his change, and there are no transactions still running who need to see the previous versions of the row, InnoDB has a background thread that gradually cleans up those old versions.

This is important for example for reporting applications that want to run multiple queries and they want all the subtotals to match. If the latter queries in the report saw a slightly updated view of the database, they could get different results than the earlier queries.

You may optionally change the transaction isolation level to READ-COMMITTED, so User 2 would automatically have his "view" of the database refreshed continually, to see the updated name Johnathon Smith (sic) but only after User 1 commits. If User 1 hasn't committed yet, User 2 cannot see the change.

You can even change the transaction isolation level to READ-UNCOMMITTED, so User 2 can see the updates even before User 1 commits. But this is rarely what you want to do -- User 1 could roll back, because Johnathon is obviously a misspelling of Jonathan.

You can experiment to test all this yourself, by opening two shell windows running mysql clients, and hop back and forth between them and see how changes become visible from one session to the other.

You'll want to learn how to use the SET TRANSACTION statement to change each session's transaction isolation level.

MySQL Transaction Timing

1 Answers1