Is incrementing a field in MySQL atomic?

Question

I'm making a web site where I would like to increment a counter in a standard MyISAM table.

Simplified example:

UPDATE votes SET num = num + 1;

Will this cause problems if multiple connections are doing the same query, or will MySQL take care of it and lock the table or something to make sure that there are no conflicts?

Answer 1

MyISAM tables use table level locking. This means that the whole table will be locked during the execution of your update query. So the answer for your simplified use case is: yes, this is thread safe. But this may not be the case if you use another storage engine or your update includes multiple tables.

Here is a quote from the MySQL manual for more clarity:

Table locking enables many sessions to read from a table at the same time, but if a session wants to write to a table, it must first get exclusive access. During the update, all other sessions that want to access this particular table must wait until the update is done.

You can also consider using auto increment columns, transactions or external synchronization if that fits to your design.

Cheers!

Answer 2

The write is atomic but an increment also requires a read. So the question is: Are you sure the read is safe, in other words, are you sure another thread doing the increment will not end up with the same value to be incremented? I have doubts. The 100% correct way of doing this would be.

-- begin transaction here

select counter from myCounters where counter_id = 1 FOR UPDATE;

-- now the row is locked and nobody can read or modify its values

update myCounters set counter = ? where id = 1;

-- set ? to counter + 1 programmatically

commit; -- and unlock...

Answer 3

Yes, the table (or rows in InnoDB format databases) is automatically locked when you execute an update query.

Answer 4

This form of UPDATE is atomic. Other forms of UPDATE can be made atomic by using transactions with SELECT ... FOR UPDATE.

Answer 5

Had the same issue, although query was more complicated:

UPDATE CLB_SYNC_T SET PENDING_MESSAGES = PENDING_MESSAGES + ? WHERE USER_ID = ?

Using MyISAM as a default engine did not help, so I fallback to SELECT FOR UPDATE use.

With SELECT FOR UPDATE performance improved ~ 10 times, since MySQL did not lock whole table, to make a row update.

Answer 6

Another approach when using InnoDB is using unique index on multiple column as follow:

Table 'Sessions' { unique_key(browser_session_id,profile_id) // ensures that inserting 1 entry per session will occur once }

select count(browser_session_id) from Sessions

Will guarantee result of unique sessions, as multiple sessions per user is not allowed.

Conclusions

• Advantage

  Each insert does require a pre-select.

• Disadvantage

  It is not suitable for all cases.

  May slow down write performance, and requires extra management