On duplicate key update lock conditions

Asked 2 years ago, Updated 2 years ago, 42 views

Access MySQL on AWS RDS

When adding API (Apache+Fuel PHP) and performing load test While Apache stopped accepting connections,
Waiting for RDS logs on RDS performance insights

synch/cond/mysys/my_thread_var::suspend

It seems that the lock has occurred.

The new MySQL code is as follows

INSERT INTO user_states
        (user_id, x, y, state)
        VALUES ('xxxxxxxx', 100, 200, 0)
        ON DUPLICATE KEY UPDATE 
        x = VALUES(x), y = VALUES(y), state = VALUES(state)

If you have a record of user_id, use the code
Create if you don't update x,y,state. This will flow asynchronously to the API for multiple user_ids containing duplicates

Table DDL has a unique index of user_id apart from PK below

CREATE TABLE `user_states`(
  `id`int(11) NOT NULL AUTO_INCREMENT,
  `user_id`varchar(255) NOT NULL,
  `x`decimal(9,6) NOT NULL,
  `y`decimal(9,6) NOT NULL,
  `state`int(11) NOT NULL DEFAULT '1',
  `created_at`datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at`datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY(`id`),
  UNIQUE KEY `index_user_states_on_user_id`(`user_id`)
ENGINE=InnoDB AUTO_INCREMENT=nnnnn DEFAULT CHARSET=latin1

I don't know if this query is the cause, but it's one of the features that I recently added. Is there a way to determine the cause of the lock on the RDS?

Also, if there is any problem with SQL or tables, please let me know

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.html

sync/cond/mysys/my_thread_var:suspend

For this wait event, the thread is stopped while waiting for the condition.For example, this event occurs when a thread is waiting for a table-level lock.It is recommended that you examine the workload to see which threads might get the table lock for the database instance.MySQL
For more information about table locking in , see Table Lock Problems in the MySQL document.

mysql sql

2022-09-30 10:28

1 Answers

sync/cond/mysys/my_thread_var:suspend
It's not like a deadlock has occurred.
Wait event indicating that the thread is suspended due to another lock occurring.
Once unlocked, it will automatically resume and process.

In parallel testing performed by the questioner
"Since ""Insert may come from user ID at the same time,"" it seems that INSERT processing is running in parallel for the same user_id, so it's a line lock level, but I think there will be a lock waiting."
This is not something that can be eliminated, and I think we have to accept it with this production.

If the requirement is that you can't even wait for the line lock waiting time at INSERT,
If the unique constraint of user_id has been stopped, why don't you try to INSERT it all the time to refer to the latest created_at on the SELECT side instead of UPDATE it?
This increases the amount of data and the load during SELECT, but eliminates the line lock latency during INSERT.


2022-09-30 10:28

If you have any answers or tips


© 2024 OneMinuteCode. All rights reserved.