CODEWITHSUNDEEP
mysqllockingtable-locking
Jason Baker
Jason Baker

Reputation: 198867

Why is table-level locking better than row-level locking for large tables?

According to the MySQL manual:

For large tables, table locking is often better than row locking,

Why is this? I would presume that row-level locking is better because when you lock on a larger table, you're locking more data.

Upvotes: 38

Views: 34409

Answers (5)

Raj More
Raj More

Reputation: 48048

A row Table level lock is better for a large table where major data modifications are taking place. This lets the system contend with a single lock on the table rather than having to deal with a gazillion locks (one for each row).

The RDBMS automatically escalates locking levels internally.

Upvotes: 2

S.Lott
S.Lott

Reputation: 392050

Table locking enables many sessions to read from a table at the same time

To achieve a very high lock speed, MySQL uses table locking

"I would presume that row-level locking is better because" [you lock less data].

First "better" is poorly defined in this page. It appears that better means "faster".

Row-level locking cannot (in general) be faster because of contention for locks. Locking each row of a large result set means the very real possibility of a conflict with another large result set query and a rollback.

Upvotes: 1

DVK
DVK

Reputation: 129549

  • Row locking needs more memory than table or page level locking.

  • Have to acquire many more locks with row locking, which expends more resources

From http://www.devshed.com/c/a/MySQL/MySQL-Optimization-part-2/

  • Advantages of row-level locking:

    • Fewer lock conflicts when accessing different rows in many threads.
    • Fewer changes for rollbacks.
    • Makes it possible to lock a single row a long time.

  • Disadvantages of row-level locking:

    • Takes more memory than page-level or table-level locks.
    • Is slower than page-level or table-level locks when used on a large part of the table because you must acquire many more locks.
    • Is definitely much worse than other locks if you often do GROUP BY operations on a large part of the data or if you often must scan the entire table.
    • With higher-level locks, you can also more easily support locks of different types to tune the application, because the lock overhead is less than for row-level locks.

  • Table locks are superior to page-level or row-level locks in the following cases:

    • Most statements for the table are reads.
    • Read and updates on strict keys, where you update or delete a row that can be fetched with a single key read: UPDATE tbl_name SET column=value WHERE unique_key_col=key_value; DELETE FROM tbl_name WHERE unique_key_col=key_value;
    • SELECT combined with concurrent INSERT statements, and very few UPDATE and DELETE statements.
    • Many scans or GROUP BY operations on the entire table without any writers.

Upvotes: 19

µBio
µBio

Reputation: 10758

from the (pre-edit) link

Slower than page-level or table-level locks when used on a large part of the table because you must acquire many more locks

use a row level lock if you are only hitting a row or two. If your code hits many or unknown rows, stick with table lock.

Upvotes: 28

SQLMenace
SQLMenace

Reputation: 135181

In general if you need to lock a lot of data then 1 lock on a big table is cheaper than a whole bunch of row level or page locks

Upvotes: 0

Related Questions