설명 필요: 상품권 인출기와 검토자의 논리는 하위 모듈의 탄성 필드를 통해 상품권의 가변 필드로 전송되지 않으며 획득하기 위해 하위 모듈에 침투해야 하며 각 하위 모듈의 추출 논리는 여전히 있습니다. 현재 전표 라인과 보조원장의 규모가 수천만개에 달하고 있으며, SQL 재작성 비용이 너무 높기 때문에 다중 테이블 공동 쿼리의 효율성이 다소 낮습니다.비즈니스 로직을 변경하지 않는 것을 전제로 합니다. 가능한 한 많이 코드를 작성하고 코드 구조를 변형하고 최적화를 위한 매개 변수 구성.
시도한 방법: 다음 방법을 연속적으로 시도했습니다.
SQL 튜닝
Oracle의 기본 제공 SQL 실행 계획을 다시 작성하여 재작성된 실행 계획은 그다지 좋은 결과를 얻지 못했습니다.
SQL 재작성
SQL 재작성: 여러 SQL을 하위 범주에서 큰 보기로 병합합니다. 임시 테이블로 분할 추출하는 대신 결과가 원본보다 느리고 실행 불가능합니다.
Dbms_Parallel_Execute
Dbms_Parallel_Execute, 이 병렬 처리는 세션 기반 임시 테이블을 기반으로 작업을 분해할 때 데이터를 찾을 수 없기 때문에 대부분 엔터티 테이블에 사용되며 이는 실현 불가능합니다.
파이프라인 기능
파이프라인 기능은 일반적으로 스트리밍 미디어 기술과 유사하게 쿼리의 결과 그룹을 구체화할 필요가 없습니다. 전통적인 공동 쿼리는 결과 집합을 구체화한 다음 결과를 출력하는 반면 파이프라인 기능은 즉시 결과를 반환할 수 있습니다. 실행되고 병렬로 열 수 있습니다.
파이프라인 기능 기술을 이용하여 1의 뷰에 해당하는 OBJECT와 TYPE을 설정하지만 결과는 최적화 전만큼 이상적이지 않습니다.
캐싱 기능
동일한 입력 매개변수의 경우 캐시 기능은 결과를 얻기 위해 SQL을 실행할 필요가 없으며 리턴을 직접 캐시합니다.
제작자를 획득하고 사람을 검증하는 논리를 캐시 기능으로 캡슐화하지만 credential je_header_id + credential line je_line_num의 입력 매개 변수에 대해 재사용률이 높지 않아 즉각적인 효과가 명확하지 않습니다.
구체화된 뷰
구체화된 뷰는 엔터티 테이블과 동일하며 주로 DB_LINK 상호 작용의 공동 쿼리에 사용되며 네트워크 대기로 인한 시간 소모를 피하고 시간을 위한 공간을 사용합니다.
CREATE MATERIALIZED VIEW xxxx_MV
REFRESH FORCE ON DEMAND
START WITH TO_DATE('23-06-2021 11:04:22', 'DD-MM-YYYY HH24:MI:SS') NEXT SYSDATE+5/(24*60) --每五分钟刷新一次
AS
--select 逻辑
구체화된 뷰를 사용할 때 두 가지 새로 고침 방법에 주의해야 합니다. 하나는 구체화된 뷰의 로그 테이블에 의존하지 않는 전체 새로 고침이고 다른 하나는 각 엔터티에 대한 로그 테이블을 생성해야 하는 증분 새로 고침입니다. 구체화된 뷰를 위해 설계된 테이블입니다. 이 두 가지 방법 모두 데이터베이스 성능에 영향을 미칩니다. 이것은 일정한 효과가 있지만 실시간 데이터가 지연되고 지연 시간은 구체화된 뷰의 새로 고침 시간에 따라 다릅니다.
최종 사용
구체화된 뷰 + 함수 캐시 + SQL 재작성 + (병합 비교)
하위 범주화된 계정의 모든 쿼리 논리를 구체화된 보기로 캡슐화하고 구체화된 보기를 작업 시간별로 완전히 새로 고칩니다.
Refresh 주기 동안 생성된 데이터는 병합 비교 방법을 사용하여 새로운 데이터를 보완합니다.
이 두 가지 방법을 사용하고 나니 시간이 많이 단축되었고 원래 1시간이 넘는 요청을 약 10분 정도로 단축할 수 있었다.DBMS_HPROF를 통한 코드의 계층적 분석을 통해 SELECT에서 호출되는 CCID)를 얻습니다.COA 섹션에 중국어로 설명된 기능은 시간이 많이 걸리기 때문에 이 부분에 대해 사용자 정의 기능을 만들었는데 기본적으로 캐시 기능이 있는 쉘이므로 동일한 CCID에 대해 SQL 쿼리를 실행할 필요가 없고, 캐시에서 직접 데이터를 반환하는 데 많은 시간을 절약할 수 있습니다.캐싱 기능이 있는 쉘 기능을 사용하기 위해 12분이 소요되었던 SQL을 변경한 후 2 이내로 개선할 수 있습니다. 10분의 시간을 절약할 수 있습니다.
포괄적인 변환 후 1시간 이상 걸리던 SQL을 이제 2분 동안 실행하여 결과를 생성할 수 있습니다.
요약하다
ETL 데이터 개발을 위해 후보자를 인터뷰하기 전에 최적화 방법을 묻는 경우가 있었는데 대부분의 후보자는 SQL 실행 계획 보기 + 인덱스 변환 두 가지 대답을 했습니다.
SQL 성능 최적화는 일회성 프로세스가 아니라 SQL을 재작성할 수 있는지, 현재 하드웨어 성능이 얼마나 많은 병렬성을 지원할 수 있는지, 공간을 시간으로 교환할 수 있는지 등 비즈니스 변환과 포괄적으로 결합되어야 합니다.