3일간의 성능 튜닝 동안 겪은 몇 가지 문제를 공유해 보세요.

지난 며칠 동안 고객의 프로덕션 환경(데이터베이스는 mysql 5.1)에서 이 저장 프로시저의 실행 시간이 30~40분 이상인 것을 살펴보았습니다. 요청은

이 저장 프로시저 구현:

1. 두 테이블의 쿼리(비즈니스 요구로 인해 테이블의 하위 쿼리도 포함됨)가 각각 임시 테이블에 삽입됩니다. 두 테이블의 데이터는 310W+, 120W

2. 중간에 일부 처리가 필요하며 임시 테이블의 데이터 그룹이 다른 임시 테이블에 삽입됩니다. 🎜>3. 마지막으로 임시 테이블의 데이터 그룹이 삽입됩니다. 정식 테이블에 도착하여 140W+ 데이터를 삽입했습니다

그리고 며칠 동안 성능 최적화의 길을 점점 더 나아갔습니다. 온갖 방법을 시도하고 온갖 어려움을 겪는다.

앱의 사진

다양한 시도:

1. 이 구현의 논리가 약간 복잡하다고 생각됩니다. , 내 아이디어에 따라 구현을 단순화했습니다. 그러나 성능은 향상되지 않습니다. 제가 구현한 방식은 많은 양의 데이터를 맨 앞으로 가져오고 후속 작업은 그룹별 등 이 많은 양의 데이터에 대해 작업을 수행해야 하기 때문입니다. 따라서 구현이 논리적으로 단순화되었지만 성능은 향상되지 않았습니다.

2. 서로 다른 논리적 식별자를 기반으로 두 세트의 임시 테이블이 생성되므로 한 테이블의 데이터 양이 너무 크지 않아 후속 작업에 대한 부담을 줄일 수 있습니다. 그래도 실패로 끝났습니다. 그 이유는 논리적 식별자 설정으로 인해 모든 것이 하나의 논리 집합을 기반으로 하기 때문입니다. 두 번째 논리 집합은 단지 형식일 뿐 실제로 수백만 개의 데이터가 있는 테이블을 확인하지 않으므로 여전히 테이블에 압력이 가해집니다. 3백만 개가 넘는다.

3. 준비된 진술을 사용하세요. 사실 저는 문장 전처리 메커니즘에 대해 잘 모릅니다. 방금 전처리가 더 효율적이라는 말을 들었습니다. 유사한 쿼리나 삽입이 많지 않기 때문에 성능이 여전히 향상되지 않습니다. 흠, 전처리 메커니즘을 잘 모르겠습니다.

4. 하위 쿼리를 제거하고 임시 테이블을 사용하여 데이터의 이 부분을 저장합니다. 이런 식으로 300만 개가 넘는 데이터가 포함된 테이블은 여전히 ​​두 번 확인해야 하며 성능 향상은 없습니다.

5. 임시 테이블의 엔진을 myisam에서 memory로 변경하고 데이터베이스의 전역 변수 max_heap_table_size 및 tmp_table_size를 프로덕션 환경과 동일한 1000M로 설정합니다. 결과는 여전히

The table 'tmp_item_bu_parter_price' is full

인데 데이터 양이 너무 많아서 메모리가 터지는 걸까요?

여섯째, 나도 다른 논리를 따랐지만 모두 같은 논리를 따른다는 것을 알았습니다. 이게 좀 단점이군요. 예전부터 고민을 많이 해서 고객의 설정을 먼저 알아내지 못했어요.

7. 멀티스레딩. insert into ...select... 구문이 저장 프로시저에서 사용되고 where 조건이 인덱싱되지 않으므로 전체 테이블 잠금이 발생합니다. 멀티 스레드 테스트의 결과는 의심할 여지없이 잠금 테이블이며 일부 데이터 실행이 실패합니다.

8. 논리적으로는 전체가 삽입되지 않고 증분으로 삽입되지만 기존 데이터는 계속 업데이트되어야 합니다. 따라서 성능은 거의 동일해야 합니다.

성능은 주로 수백만 개의 데이터를 삽입하여 소모됩니다. 이제 나는 완전히 당황했고 어떻게 대처해야 할지 모르겠습니다.

[관련 추천]

1.

무료 mysql 온라인 동영상 튜토리얼

MySQL 최신 매뉴얼 튜토리얼

3. 데이터베이스 설계에 관한 사항

위 내용은 3일간의 성능 튜닝 동안 겪은 몇 가지 문제를 공유해 보세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!