'Updating'상태에서 MySQL/InnoDB의 일부 업데이트가 매우 느리게 실행됩니다.

Google 데이터베이스에서 UPDATE 성능이 상당히 느려지는 경우가 있습니다.'Updating'상태에서 MySQL/InnoDB의 일부 업데이트가 매우 느리게 실행됩니다.

예를 들어 FooTable 테이블에는 varchar PK가 포함 된 약 40 개의 열과 10 개의 인덱스가 있습니다. 다음 쿼리는 44 초가 걸리는 반면 다른 시간에는 거의 즉시 실행됩니다. 속도가 느려지는 동안 서버의로드 평균은 매우 낮으며 (평균 5 분의 1.5) vmstat 당 IO는 상당히 합리적입니다. 여기에 예를 들어

:이 예제 쿼리 위 (ALTER TABLE FooTable의 ENGINE = InnoDB의를) '재건'된 InnoDB의 테이블에 실행 된 가치가 무엇인지에 대한

mysql> update FooTable set BarColumn=1349981286086 where varcharPK='e4348411-0fbb-460a-80f7-f1de304a9f7c' 
Query OK, 1 row affected (44.94 sec) 
Rows matched: 1 Changed: 1 Warnings: 0 

mysql> show profile for QUERY 1; 
+----------------------+-----------+ 
| Status    | Duration | 
+----------------------+-----------+ 
| starting    | 0.000030 | 
| checking permissions | 0.000004 | 
| Opening tables  | 0.000007 | 
| System lock   | 0.000003 | 
| Table lock   | 0.000003 | 
| init     | 0.000035 | 
| Updating    | 44.949727 | 
| end     | 0.000006 | 
| query end   | 0.000003 | 
| freeing items  | 0.000115 | 
| logging slow query | 0.000002 | 
| logging slow query | 0.000052 | 
| cleaning up   | 0.000003 | 
+----------------------+-----------+ 
13 rows in set (0.02 sec)

일주일 전에 적은 다음. 처음에는 이것이 InnoDB의 varchar/non sequential PKS에 대한 알려진 성능 문제와 관련이 있다고 의심했지만, 순차적 PK를 사용하는 다른 테이블이 있고 동일한 문제가 발생했습니다. 2.6.18-238.19.1.el5 x86_64에 MySQL이/Percona 데이터 58.8G과 메모리 테이블 (87)에 걸쳐 확산 96기가바이트를 5.1.57-rel12.8 로그 를 CentOS 5

이 생산 서버에 이 테이블에 COMPRESSED 나는 형식을 사용하고 있지 않다

innodb_flush_log_at_trx_commit = 2 
innodb_buffer_pool_size   = 70G 
innodb_log_file_size   = 512M 
innodb_log_buffer_size   = 64M 
innodb_file_per_table   = 1 
innodb_thread_concurrency  = 0 
innodb_flush_method    = O_DIRECT 
innodb_read_io_threads   = 64 
innodb_write_io_threads   = 64 
optimizer_search_depth   = 0 
innodb_file_format    = barracuda

을 = 그러나 나는 다른 사람에 오전, 다음과 같이

와 관계있는의 InnoDB의 설정은 다음과 같습니다.

너무 오래 걸리는 업데이트 단계에서 어떤 일이 일어나는지 파악하는 방법에 대한 제안 사항이 있으십니까?

출처

2012-10-12 Jeremy

'EXPLAIN이 (가) 'UPDATE'와 (과) 함께 작동합니까? 'SELECT barColumn FROM FooTable WHERE varCharPK = ... '를 사용하여 동일한 성능을 얻으십니까? 나는 그것이 인덱스로 이상한 일을하는지 궁금해. –

UPDATE에서 Explain을 실행할 수는 없지만 SELECT로 변환하면 PRIMARY 키가 1 행으로 사용됩니다. – Jeremy

쿼리가 실행되는 동안 "SHOW PROCESSLIST"를 수행하십시오. 테이블에 대한 잠금이있는 다른 쿼리를 보여줄 수 있습니다. – bobwienholt

근본적인 원인은 장기간 실행 된 응용 프로그램 트랜잭션이었습니다. 해결책은 대규모 트랜잭션을 더 작은 단위로 세분화하는 것이 었습니다.

출처

2012-10-19 15:44:07 Jeremy

varcharPK-field에서 해시 인덱스를 사용하는 방법 (varcharPK를 텍스트로 변환하는 방법)은 무엇입니까?

테이블 변경은 추가 FooTable KEY pk_index (varcharPK (100)) HASH

한번 비슷한 문제가 있었이 도움이 사용. 내가 너에게 도움이 될지 모르겠다. 당신이 테이블을 나눌 수 있다면 그것은 또한 도움이 될 것 같은 소리입니다 - 그것은 "너무 많은"데이터를 가지고 있습니다.

출처

2012-10-15 19:17:12 viljun

이 변경 사항의 논리를 설명해 주시겠습니까? – Jeremy

해시 된 인덱스를 사용하면 인덱스 공간이 적어 검색 및 유지 관리가 더 빠릅니다. 이것을 확인하십시오 : http://stackoverflow.com/questions/12689460/how-to-index-innodb-text-in-mysql – viljun

또한 텍스트는 테이블 데이터 (예 : varchar)와 함께 저장되지 않으므로 모든 것을 만들 수도 있습니다. 빠릅니다. – viljun

'Updating'상태에서 MySQL/InnoDB의 일부 업데이트가 매우 느리게 실행됩니다.

답변

관련 문제