MySQL 업데이트도 오랜 시간이 걸렸습니다.

Question

갑자기 일부 업데이트가 갑자기 길어지면서 테이블이 약 2MM 레코드에 도달 할 때까지 꽤 오래 걸렸습니다. 각 60 초.

mysql> show profile context switches 
    -> ; 
+----------------------+-----------+-------------------+---------------------+ 
| Status    | Duration | Context_voluntary | Context_involuntary | 
+----------------------+-----------+-------------------+---------------------+ 
| (initialization)  | 0.000007 |     0 |     0 | 
| checking permissions | 0.000009 |     0 |     0 | 
| Opening tables  | 0.000045 |     0 |     0 | 
| System lock   | 0.000009 |     0 |     0 | 
| Table lock   | 0.000008 |     0 |     0 | 
| init     | 0.000056 |     0 |     0 | 
| Updating    | 46.063662 |    75487 |    14658 | 
| end     | 2.803943 |    5851 |     857 | 
| query end   | 0.000054 |     0 |     0 | 
| freeing items  | 0.000011 |     0 |     0 | 
| closing tables  | 0.000008 |     0 |     0 | 
| logging slow query | 0.000265 |     2 |     1 | 
+----------------------+-----------+-------------------+---------------------+ 
12 rows in set (0.00 sec) 

: 결과 높은 수치를 보인다 하나만있는 프로파일에서

`id` bigint(20) NOT NULL auto_increment, 
`field1` int(11) default '0', 

결과 콘텍스트 스위치 : 여기

update table1 set field1=field1+1 where id=2229230; 
Query OK, 0 rows affected (42.31 sec) 
Rows matched: 1 Changed: 0 Warnings: 0 

은 필드 종류 이 테이블은 약 250 만 레코드이고 ID는 기본 키이며 다른 필드에 하나의 고유 인덱스가 있습니다 (업데이트에 포함되지 않음).

무단 전재 표입니다.

원인에 대한 설명이 있습니까?

문제를 추적하는 데 도움이되는 특정 변수는 무엇입니까?

업데이트에 대한 설명이 있습니까?

편집 : 또한 그냥 테이블도 있습니다 것으로 나타났습니다 A :

`modDate` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, 

설명 : ID가 정말 기본 인 경우

가

+----+-------------+---------------+-------+---------------+---------+---------+-------+------+-------+ 
| id | select_type | table   | type | possible_keys | key  | key_len | ref | rows | Extra | 
+----+-------------+---------------+-------+---------------+---------+---------+-------+------+-------+ 
| 1 | SIMPLE  | table1  | const | PRIMARY  | PRIMARY | 8  | const | 1 |  | 
+----+-------------+---------------+-------+---------------+---------+---------+-------+------+-------+ 
1 row in set (0.02 sec) 

Answer 1

, 해당 쿼리 시간이 오래 걸릴한다 방법은 없습니다 키가 없으면 (2229230과 같은 많은 수의 ID가없는 경우)? 다음과 같은 두 가지 SQL을 실행하고 그 결과를 게시하시기 바랍니다 :

show create table table1; 
explain select * from table1 where id = 2229230; 

업데이트 :

OPTIMIZE TABLE table1; 

을 때때로 당신을 : 단지 또한이

가

select count(*) from table1 where id = 2229230; 

Answer 2

은 나뿐만 아니라 추천 수 수행 완료하기 테이블은 단지 약간의 사랑이 필요합니다. 그들이 빠르게 성장하고 잠시 동안 인덱스를 최적화하지 않았다면 인덱스가 약간 미칠 수도 있습니다. 당신은 시간이있어 (그리고 당신이 할) 경우에 실제로, 그것은, 그 원인은 "중복 인덱스 '이었다 보인다이 하나를 추적의 몇 시간 후 확인

REPAIR TABLE table1; 

Answer 3

에 던져 결코 아프지 않는다 는, 내가 키스에 대답하고 있던 테이블을 만드는이 이상한 콤보를했다 :

• fieldx 두 번째는 분명히 중복과 쓸모가

에 fieldx

키에 고유 키, 하지만 내가 떨어 뜨린 후에 키를 누 르면 모든 업데이트가 < 1 초가되었습니다.

+1 Keith와 Ivan의 의견은 마침내 문제를 추적하는 데 도움이됩니다.

Answer 4

나에게 도움이 된 것은 엔진을 'innodb'에서 'myisam'으로 변경하는 것이 었습니다. 비슷한 크기의 데이터 집합에 대한 내 업데이트 쿼리가 100ms에서 0.1ms로 변경되었습니다.

기존 애플리케이션의 엔진 유형을 변경하면 InnoDB의 데이터 무결성이 향상되고 애플리케이션에 따라 기능이 달라질 수 있으므로주의해야합니다.

빅 데이터 세트에서 1000 배 속도 향상을 위해 InnoDB를 잃어 버릴 가치가있었습니다.

Answer 5

나는 테이블에 방아쇠를 당긴 것으로 밝혀졌다. 내 테이블에서 업데이트가 수행 될 때마다 트리거는 실제로 지연이 발생한 다른 테이블을 업데이트합니다. 해당 테이블에 색인을 추가하면 문제가 해결되었습니다. 따라서 테이블에서 트리거를 확인하십시오.

Answer 6

select 문과 비교할 때 너무 많은 시간이 걸리는 업데이트 문을 디버깅 할 때 고려해야 할 또 다른 사항은 은 트랜잭션 내에서 실행되는 업데이트 명령문입니까?

필자의 경우 트랜잭션이 업데이트 명령문을 매우 빠른 실행 시간에서 매우 느린 실행 시간으로 변경했습니다. 영향을받는 행이 많을수록 성능이 저하됩니다. 내 명령문은 사용자 정의 변수와 함께 작동하지만 '문제'의 해당 부분을 모릅니다.