Slow SQL (Update by Primary Key)

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 慢sql(根据主键更新)

| username: Hacker_QfCMflZ4

【TiDB Usage Environment】Production Environment
【TiDB Version】7.0.0
【Reproduction Path】Observed an update taking 2.7s in slow SQL monitoring, updating based on the primary key
【Encountered Problem: Phenomenon and Impact】

UPDATE
  `wfc_batch_operate_log`
SET
  `update_time` = '2023-06-25 15:09:50'
WHERE
  `id` = 878221950497316865;

It’s a very simple SQL to update the time based on the primary key.
【Resource Configuration】


【Attachments: Screenshots/Logs/Monitoring】


| username: tidb菜鸟一只 | Original post link

Is it also slow when executed manually?

| username: zhanggame1 | Original post link

The only consideration is whether there were other transactions updating this data at that time.

| username: 有猫万事足 | Original post link

I agree with @zhanggame1’s statement, there should be a lock. You can see there is a lock in the information. Additionally, here is the execution plan I updated myself. There is no such lock.

| username: redgame | Original post link

There is indeed a lock in the information.

| username: 我是咖啡哥 | Original post link

It should be caused by concurrent updates.

| username: Anna | Original post link

Observe the concurrency.

| username: linnana | Original post link

Concurrent lock waiting is possible.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.