SQL 문 효율성 문제 요약

1. SQL 최적화의 원칙은 다음과 같습니다.

한 번의 작업으로 읽어야 하는 BLOCK 수를 최소화합니다. 즉, 최단 시간에 최대 데이터 처리량을 달성합니다.
잘못된 SQL 조정은 일반적으로 다음 사항부터 시작할 수 있습니다.
잘못된 SQL을 확인하고 작성 시 최적화할 수 있는 부분이 있는지 고려하세요.
하위 쿼리 확인 SQL 하위 쿼리를 재구성할 수 있는지 고려하세요. 간단한 연결 사용 쓰기
최적화된 인덱스 사용 확인
데이터베이스 최적화 고려

2. SELECT * FROM 테이블 문을 피하고 확인할 필드가 명확한지 확인하세요.
<.> 3. SQL 문에서 where 조건으로 필터링된 데이터베이스가 많을수록

위치 지정이 더 정확할수록 앞으로 더 많이 이동해야 합니다.

4. 쿼리할 때 가능하면 인덱스 범위를 사용하세요. 즉, SELECT 필드

에 대해 복합 인덱스가 생성됩니다. 이렇게 쿼리 중에는 인덱스 스캔만 수행되고 데이터 블록은 읽히지 않습니다.

5. 조건에 맞는 레코드가 있는지 판단할 때 SELECT COUNT(*)를 사용하지 않고 상위 1개 문을 선택하는 것이 좋습니다.

6. SQL 문을 작성할 때 내부 제한 원칙을 사용하고 쿼리 조건을 분해하여 분류하고

SQL 문의 가장 안쪽 계층을 제한하여 데이터 처리량을 줄이도록 노력하십시오. 

 
7. order by 절에서는 표현식을 절대 피해야 합니다.

8. 관련 테이블의 데이터를 읽어야 하는 경우 관련 테이블 수는 일반적으로 7개를 초과하지 않아야 합니다.

9. IN 및 OR을 주의해서 사용하세요. In 컬렉션의 데이터 양에 주의하세요. 컬렉션의 데이터는 200개를 초과하지 않는 것이 좋습니다. ~                           다음으로 대체됨

11. 쿼리 시 중복 열과 중복 행을 포함한 중복 데이터 읽기를 줄여보세요.

12. 복합 인덱스에 주의하세요. 예를 들어, 복합 인덱스를 구축할 때 열의 순서는 F1, F2, F3,

그러면 이러한 필드가 나타나는 순서입니다. where 또는 order by 절에서 인덱스를 생성할 때 필드 순서를 유지하려면

및 첫 번째 열을 포함해야 합니다. F1 또는 F1, F2 또는 F1, F2, F3만 가능합니다. 그렇지 않으면 인덱스가 사용되지 않습니다.

13. 다중 테이블 관련 쿼리를 수행할 때 작성 방법은 다음 원칙을 따라야 합니다. 이는 인덱스 구축 및 쿼리 효율성을 높이는 데 도움이 됩니다.

형식은 다음과 같습니다

table1 table1, table2 table2, table3 table3에서 sum(table1.je)을 선택합니다. 여기서 (= )) 및 (table1 비동등 조건)

and (table2와 table1 간의 연관 조건) and (table2의 동치 조건) and (table2의 비동등 조건)

and (table3과 table2 연관 조건) and (동등 조건 표3의) 및 (표3의 비동등 조건). ​

​ 참고: 다중 테이블 쿼리 중 후속 테이블의 표시 순서가 효율성에 미치는 영향은 아직 연구되지 않았습니다.

14. 하위 쿼리 문제입니다. 조인이나 뷰를 사용하여 구현할 수 있는 기능의 경우 하위 쿼리를 사용하지 마세요.

예:

customer_id가 있는 고객에서 이름을 선택합니다(돈>1000인 주문에서 customer_id 선택).

은 다음 문으로 대체되어야 합니다. 고객의 이름 선택

customer.customer_id=order.customer_id

에서 order.money>100의 내부 조인 순서. ​

 

15. WHERE 절에서는 열에 대한 4가지 산술 연산을 피하세요.

특히 where 조건의 왼쪽에서는 컬럼을 처리하기 위한 연산 및 함수를 사용하는 것이 엄격히 금지됩니다.

예를 들어 일부 위치에서는 하위 문자열을 like로 대체할 수 있습니다.

16. 문에 in(in) 작업이 없으면

은 not presents(exists)로 다시 작성되는 것으로 간주해야 합니다.
17. 비즈니스 프로세스의 처리는 사물 사이의 시작 시간과 끝 시간을 만들어야 합니다.

원칙적으로 데이터베이스 쓰기 작업은 교차를 피하기 위해 나중에 완료됩니다.

18. 너무 많은 열에 대해 열 기능과 정렬 기준, 그룹 기준 등을 사용하지 않도록 주의하고 disti 소프트웨어 개발을 주의해서 사용하십시오.

19. Union 대신 Union All을 사용합니다.

먼저 Union의 양쪽 끝에 각각 쿼리를 실행합니다. 테이블을 선택한 다음 정렬하여 중복 레코드를 필터링합니다.​

​ 알려진 비즈니스 로직에서 쿼리 A와 쿼리 B에 중복된 레코드가 없을 것이라고 판단하는 경우

​는 쿼리 효율성을 높이기 위해 Union 대신 Union ​을 사용해야 합니다.