php - MYSQL Update Query randomly takes a long time

I have a php script on a webserver which is called ones per second. This script accesses a mysql database and reads/updates some information. Most of the time the script returns the result in <30ms. Sometimes however, the scripts takes 4-8 seconds.

The table which is edited only has 1 row and 4 columns.

By recording the time different parts of the script use, i have found that the time is always consumed by the first UPDATE query. This is also the case if the order of the queries is changed.

I have also tried putting everything in one mySql transaction, then the commit function takes the time normaly used by the first UPDATE query.

I have checked for locked tables via "show open tables WHERE In_use > 0"; but none are found.

The code for the query which normaly takes the time is below:

// Add Timestamp
echo ("BeforeTimestamps Updated" . (time()- $time) . "Seconds"); // DEBUG DEBUG DEBUG
$time =  time();
// Try updating Timestamp
$sql = "UPDATE $LobbyID SET lastconnect=$reftime WHERE id = $PlayerID";
$conn -> query($sql);
echo ("Timestamps Updated" . (time()- $time) . "Seconds"); // DEBUG DEBUG DEBUG

So for some reason sometimes the first update query for a connection takes multiple seconds, and I have no idea why. So if anyone can help, I would be very happy.

Edit: As Requested in the comments; here is the SHOW CREATE TABLE

+

Answer

+

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

--+ | Table | Create Table | +

Answer

+

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

--+ | L2787828 | CREATE TABLE `L2787828` ( `id` int unsigned NOT NULL, `type` varchar(2) NOT NULL, `command` text NOT NULL, `lastconnect` int NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci | +

Answer

+

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

Answer

--+

Answer

Solution:

(Apologies if I am jumping to the wrong conclusion.)

How many tables do you have? L2787828 makes me worry that you might have 2787828 tables! That is a serious problem -- There is limited caching space for tables, opening (and the necessary closing) of lots and lots of tables would be very inefficient. It is much more efficient to have all similar tables combined into a single table with an extra column to distinguish the rows as needed.

(It is quite OK to have a table with a single row, even a single column, but if it is not one of many similar tables.)

The timing would be explained by:

  • Bump some other "open table" out of table_open_cache.
  • Open L2787828 -- This involves touching at least two files via the OS, plus some meta tables inside InnoDB.
  • And then proceed with the UPDATE.

Source