DBA가 당신을 사랑하게 만드는 5가지 SQL 팁

1. 인덱스 열에서 Function을 호출하지 마세요.

이렇게 하면 데이터베이스가 이 인덱스를 사용하지 못하게 됩니다. 이렇게 하면 지정된 파티션에서 읽을 수 없기 때문에 이 문제는 분할된 테이블에도 영향을 미칠 수 있습니다. 데이터를 검색하려면 전체 테이블스페이스를 스캔하십시오. 데이터 볼륨이 큰 데이터 테이블의 경우 이는 치명적인 성능 재앙이 될 것입니다.

하지 말아야 할 것:

WHERE
TIME_ID+14 > to_number(to_char(sysdate,'J'))

해야 할 것:

WHERE
TIME_ID > to_number(to_char(sysdate-14,'J'))

2. 분석을 사용하여 복잡한 SQL을 최적화합니다

그렇게 하면 데이터베이스의 쿼리 최적화 프로그램 사용을 거부하고 최적화된 연결을 사용할 기회를 잃게 됩니다. 100만 개의 레코드가 포함된 임시 테이블을 생성한다고 가정해 보겠습니다. 분석되지 않으면 최적화 프로그램은 기존 단서에서 테이블의 실제 내용을 얻을 수 없으므로 중첩 루프 조인을 사용하여 스캔하기만 결정할 수 있습니다. 데이터의 양이 크지 않으면 성능 저하를 느끼지 못할 수 있지만, 데이터 세트가 늘어나면 데이터베이스 성능은 점점 더 나빠질 것입니다.

권장 사항은 다음과 같습니다.

ANALYZE TABLE <TABLE_NAME> COMPUTE STATISTICS

3. 복잡한 SQL을 여러 단계로 나누어 실행합니다.

SQL을 피자라고 생각하지 마세요. 피자 한 조각을 입에 넣고 씹을 수 있을 거예요.

복잡한 SQL 쿼리를 생성하려면 3~4단계로 나누는 것이 좋습니다. SQL이 단순할수록 옵티마이저의 효과는 더 좋아야 합니다. 또한 각 데이터 테이블의 데이터는 더 쉬워야 합니다. 디버그하는 것입니다.

4. 필요한 경우에만 Distinct를 사용하세요

이것은 매우 좋은 경험 법칙입니다. Distinct는 2개 이상의 중복 레코드를 반환하는 SQL 쿼리에 자주 사용됩니다. Distinct를 사용하면 중복 데이터 레코드가 발생합니다. 필터링됩니다. 단, Distinct를 사용하는 목적이 명확해야 하며, 반환되는 레코드가 사용자 ID와 같이 고유해야 한다는 것이 확실한 경우에만 사용할 수 있습니다. Distinct를 남용하면 다중 테이블 조인 쿼리와 같은 예측할 수 없는 오류가 발생합니다.

5. 합리적으로 인덱스 생성

마지막 포인트는 합리적으로 테이블 인덱스를 생성하는 것입니다. 간단히 말해서, 100,000개의 레코드가 있는 데이터 테이블이 있다면 다음과 같은 정보를 쿼리하는 경우가 많습니다. 이 테이블에 있는 내 고객 정보 중 하나인가요?" 인덱스를 사용하면 이 고객 정보를 검색하는 속도가 매우 빨라집니다. 그렇지 않으면 데이터베이스 최적화 프로그램이 전체 테이블 스캔을 선택하게 되는데, 이는 대용량 데이터 볼륨의 경우 악몽입니다.