MySQL Table Lock Waits Test

A lock is a mechanism associated with a table used to restrict the unauthorized access of the data in a table. MySQL allows a client session to acquire a table lock explicitly to cooperate with other sessions to access the table's data. MySQL also allows table locking to prevent it from unauthorized modification into the same table during a specific period.

A session in MySQL can acquire or release locks on the table only for itself. Therefore, one session cannot acquire or release table locks for other sessions. It is to note that we must have a TABLE LOCK and SELECT privileges for table locking.

Table Locking in MySQL is mainly used to solve concurrency problems. It will be used while running a transaction, i.e., first read a value from a table (database) and then write it into the table (database).

MySQL provides two types of locks onto the table, which are:

  • READ LOCK: This lock allows a user to only read the data from a table.

  • WRITE LOCK: This lock allows a user to do both reading and writing into a table.

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, meaning it might have to wait for other sessions to finish with the table first. During the update, all other sessions that want to access this particular table must wait until the update is done. Table locking causes problems when a session is waiting because the disk is full and free space needs to become available before the session can proceed. In this case, all sessions that want to access the problem table are also put in a waiting state until more disk space is made available. if the number of lock waits grows over time, it will consequently increase the length of the pending requests queue; a long request queue may not only cause the unnecessary erosion of valuable server resources, it may also choke the database server, thereby significantly impacting the quality of the user experience with the server. It is therefore imperative that the lock wait events are monitored, and issues related to such events immediately brought to the attention of administrators.

This test monitors the table lock wait events, and promptly alerts administrators to a sudden/ steady increase in the number and duration of such events.

Target of the test : A MySQL server

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for the target MySQL database server being monitored

Configurable parameters for the test
Parameter Description

Test period

This indicates how often should the test be executed.


Specify the HOST for which this test is to be configured.


Specify the port at which the target host is listening.


Specify the name of a database on the target MySQL database server being monitored.

Username and Password

The eG agent has to be configured with the credentials of a user who has server-wide Process and Select privileges on the monitored MySQL server. To know how to create such a user, refer to Pre-requisites for Monitoring the MySQL Server topic.

Confirm Password

Confirm the password by retyping it here.

DD Row Count

By default, the detailed diagnosis of this test, if enabled, will report only the top-10 tables. This is why, the DD Row Count parameter is set to 10 by default. If you want to include more or less tables in detailed diagnosis, then change the value of this parameter accordingly.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Session waiting

Indicates the number of sessions waiting for the lock during the last measurement period.



Maximum wait time for table lock

Indicates the maximum time spent by a query while waiting for a table lock.


If the value of this measure is high, there may be an impact on the performance of the database server. To improve the performance, administrators need to optimize the queries, either split one / more tables or use replication.

The detailed diagnosis of this measure lists Thread ID, Statement ID, Schema name, Query duration, Table lock wait time (Seconds), Temp disk tables created, Temp tables created, Rows sent, Rows examined, Select scan, Sort scan and SQL text.