1. SQL 최적화의 원칙은 다음과 같습니다.
한 번의 작업으로 읽어야 하는 BLOCK 수를 최소화합니다. 즉, 최단 시간에 최대 데이터 처리량을 달성합니다.
잘못된 SQL 조정은 일반적으로 다음 사항부터 시작할 수 있습니다.
잘못된 SQL을 확인하고 작성 시 최적화할 수 있는 부분이 있는지 고려하세요.
하위 쿼리 확인 SQL 하위 쿼리를 재구성할 수 있는지 고려하세요. 간단한 연결 사용 쓰기
최적화된 인덱스 사용 확인
데이터베이스 최적화 고려
2. SELECT * FROM 테이블 문을 피하고 확인할 필드가 명확한지 확인하세요.
<.> 3. SQL 문에서 where 조건으로 필터링된 데이터베이스가 많을수록
4. 쿼리할 때 가능하면 인덱스 범위를 사용하세요. 즉, SELECT 필드
6. SQL 문을 작성할 때 내부 제한 원칙을 사용하고 쿼리 조건을 분해하여 분류하고
7. order by 절에서는 표현식을 절대 피해야 합니다.
8. 관련 테이블의 데이터를 읽어야 하는 경우 관련 테이블 수는 일반적으로 7개를 초과하지 않아야 합니다.
9. IN 및 OR을 주의해서 사용하세요. In 컬렉션의 데이터 양에 주의하세요. 컬렉션의 데이터는 200개를 초과하지 않는 것이 좋습니다. ~ 다음으로 대체됨
11. 쿼리 시 중복 열과 중복 행을 포함한 중복 데이터 읽기를 줄여보세요.
12. 복합 인덱스에 주의하세요. 예를 들어, 복합 인덱스를 구축할 때 열의 순서는 F1, F2, F3,
그러면 이러한 필드가 나타나는 순서입니다. where 또는 order by 절에서 인덱스를 생성할 때 필드 순서를 유지하려면
참고: 다중 테이블 쿼리 중 후속 테이블의 표시 순서가 효율성에 미치는 영향은 아직 연구되지 않았습니다.
14. 하위 쿼리 문제입니다. 조인이나 뷰를 사용하여 구현할 수 있는 기능의 경우 하위 쿼리를 사용하지 마세요.
예:
customer_id가 있는 고객에서 이름을 선택합니다(돈>1000인 주문에서 customer_id 선택).
15. WHERE 절에서는 열에 대한 4가지 산술 연산을 피하세요.
특히 where 조건의 왼쪽에서는 컬럼을 처리하기 위한 연산 및 함수를 사용하는 것이 엄격히 금지됩니다.
예를 들어 일부 위치에서는 하위 문자열을 like로 대체할 수 있습니다.
16. 문에 in(in) 작업이 없으면
은 not presents(exists)로 다시 작성되는 것으로 간주해야 합니다.
17. 비즈니스 프로세스의 처리는 사물 사이의 시작 시간과 끝 시간을 만들어야 합니다.
19. Union 대신 Union All을 사용합니다.
알려진 비즈니스 로직에서 쿼리 A와 쿼리 B에 중복된 레코드가 없을 것이라고 판단하는 경우
는 쿼리 효율성을 높이기 위해 Union 대신 Union 을 사용해야 합니다.