반응형
기본 키를 사용하여 행을 업데이트할 때 MariaDB 고정
표에서 사용자의 마지막 활동을 업데이트할 때 MariaDB(10.1)에서 교착 상태에 빠집니다.
오류의 원인이 되는 쿼리는
UPDATE auth_sessions SET last_activity_time='2018-12-21 05:45:39 WHERE id= 481;
사용자가 응용프로그램에서 작업을 수행할 때마다 절차 내에서 이 쿼리를 실행합니다.
다음은 수신된 상태입니다.show engine innodb status ;
------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-12-21 05:45:39 7fe5b8e6eb00
*** (1) TRANSACTION:
TRANSACTION 3742528, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 12 lock struct(s), heap size 2936, 81 row lock(s)
MySQL thread id 1941, OS thread handle 0x7fe5b5df4b00, query id 43106 localhost 127.0.0.1 root updating
UPDATE auth_sessions
SET last_activity_time= NAME_CONST('time_now',_latin1'2018-12-21 05:45:39' COLLATE 'latin1_swedish_ci')
WHERE id= NAME_CONST('temp_session_id',481)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 470949 page no 6 n bits 160 index `PRIMARY` of table `xfusion_auth_engine`.`auth_sessions` trx table locks 5 total table locks 5 trx id 3742528 lock_mode X locks rec but not gap waiting lock hold time 0 wait time before grant 0
*** (2) TRANSACTION:
TRANSACTION 3742527, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
12 lock struct(s), heap size 2936, 81 row lock(s)
MySQL thread id 1943, OS thread handle 0x7fe5b8e6eb00, query id 43123 localhost 127.0.0.1 root updating
UPDATE auth_sessions
SET last_activity_time= NAME_CONST('time_now',_latin1'2018-12-21 05:45:39' COLLATE 'latin1_swedish_ci')
WHERE id= NAME_CONST('temp_session_id',481)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 470949 page no 6 n bits 160 index `PRIMARY` of table `xfusion_auth_engine`.`auth_sessions` trx table locks 5 total table locks 5 trx id 3742527 lock mode S locks rec but not gap lock hold time 0 wait time before grant 0
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 470949 page no 6 n bits 160 index `PRIMARY` of table `xfusion_auth_engine`.`auth_sessions` trx table locks 5 total table locks 5 trx id 3742527 lock_mode X locks rec but not gap waiting lock hold time 0 wait time before grant 0
*** WE ROLL BACK TRANSACTION (2)
------------
TRANSACTIONS
테이블 스키마 - 인증 세션
CREATE TABLE `auth_sessions` (
`id` INT(11) NOT NULL AUTO_INCREMENT COMMENT 'Auto Increment ID',
`user_id` VARCHAR(255) NULL DEFAULT NULL COMMENT 'User Email',
`user_key` VARCHAR(255) NULL DEFAULT NULL COMMENT 'User Key',
`application_key` VARCHAR(255) NULL DEFAULT NULL COMMENT 'Application Key',
`created` DATETIME NULL DEFAULT NULL COMMENT 'Session Creation Time',
`expires` DATETIME NULL DEFAULT NULL COMMENT 'Session Expiration Time',
`is_logged_in` TINYINT(4) NULL DEFAULT NULL COMMENT 'Tells whether user is logged in or not ',
`session_key` VARCHAR(255) NULL DEFAULT NULL COMMENT 'Session Key per user per application key',
`last_activity_time` DATETIME NULL DEFAULT NULL COMMENT 'Last recorded time for any activity',
`session_key_bin` BINARY(16) NULL DEFAULT NULL COMMENT 'Binary ID of Session Key',
PRIMARY KEY (`id`),
INDEX `ix_session_key_bin` (`session_key_bin`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
;
이 문제를 해결할 수 있는 단서나 해결책이 있습니까?
다중 문 트랜잭션이 있는 경우(없는 경우):
때때로 이것과 유사한 문제들에 대한 치료법은 가지고 있는 것입니다.
SELECT ... WHERE id= 481 FOR UPDATE;
이전에UPDATE
하지만 거래 내부에서.
모든 교착 상태를 방지할 수 있는 것은 아닙니다.교착 상태를 처리할 준비를 하는 것이 가장 좋습니다.이 특정 문제는 다음을 통해 올바르게 처리할 수 있습니다.
계획 A(권장):재생UPDATE
.
계획 B(쿼리의 목적을 고려할 때 아마도 괜찮을 것입니다):교착 상태를 무시합니다.
계획 C(효과가 있을지는 모르겠습니다. 효과가 있다면 이러한 교착 상태를 제거해야 합니다.):
UPDATE auth_sessions
SET last_activity_time = NOW()
WHERE last_activity_time != NOW()
AND id = 481;
이 방법은 값이 이미 원하는 시간으로 설정되어 있는 경우 업데이트를 시도하지 않도록 하는 것입니다.
언급URL : https://stackoverflow.com/questions/53880036/mariadb-dead-lock-when-updating-row-using-primary-key
반응형
'itsource' 카테고리의 다른 글
Android: ScrollView 내부의 View가 보이는지 확인하는 방법은 무엇입니까? (0) | 2023.08.10 |
---|---|
기본 키에 대한 SQL 데이터 유형 - SQL 서버? (0) | 2023.08.10 |
Instruments ObjectAlloc: 실시간 바이트 및 전체 바이트 설명 (0) | 2023.08.05 |
Docker for Windows가 드라이브를 공유할 수 있도록 Windows 방화벽 설정 (0) | 2023.08.05 |
Spring MVC "redirect:" 접두사는 항상 http로 리디렉션됩니다. 어떻게 하면 https를 유지할 수 있습니까? (0) | 2023.08.05 |