답변.

다중 정렬은 보고서를 작성할 때 여러 열(예: 날짜별로, 그 다음 이름별, 다음 총액별)로 데이터를 정렬하거나 그룹화해야 할 때 매우 중요한 도구입니다. 전통적으로 정렬은 엄격하게 한 필드에 대해서만 적용되었으며, 이는 데이터의 복합 분석 요구를 해결하지 못합니다.

문제는 종종 잘못된 정렬 순서(예: NULL 값이 예상치 못한 위치에 나타남), 정렬 규칙의 오류(문자열 값의 정렬 규칙) 및 대규모 데이터 집합에서 성능 저하에 있습니다.

해결책: 다중 열 ORDER BY를 사용하고, COLLATION의 특성을 고려하며, 결과의 결정성을 위해 NULLS의 순서를 명시적으로 정의하고, 큰 테이블의 열에 대한 인덱스를 확인합니다.

코드 예시:

SELECT * FROM sales
ORDER BY region COLLATE "ru_RU", date DESC NULLS LAST, total_amount DESC;

주요 특징:

전체 열 및 데이터 유형 집합에 대해 정렬을 수행할 수 있습니다.
NULL의 위치를 NULLS FIRST/LAST를 통해 명시적으로 관리합니다.
문자열 열에 대해 COLLATE를 명시적으로 설정할 수 있습니다(지원 여부는 DBMS에 따라 다름).

트릭 질문.

COLLATE를 지정하지 않으면 서로 다른 서버에서 항상 정렬이 동일할까요?

아니요! 기본 COLLATE는 데이터베이스 및/또는 서버의 설정에 따라 다르며, 문자열의 정렬 결과(특히 키릴 문자와 특수 문자)는 설치 간에 다를 수 있습니다.

정렬이 DESC와 ASC일 때 NULL은 어디로 가나요?

SQL 표준은 이를 명확하게 정의하지 않습니다. 일부 DBMS에서는 ASC일 때 NULL이 위쪽으로, 다른 DBMS에서는 아래쪽으로 갑니다. NULLS FIRST 또는 NULLS LAST를 명확하게 지정하여 동작을 투명하게 만드십시오.

ORDER BY price DESC NULLS LAST

여러 열의 ORDER BY가 인덱스 사용에 영향을 미치나요?

예, 하지만 열의 순서, 유형 및 값의 정합성이 기존의 복합 인덱스와 일치할 경우에만 그렇습니다. 순서가 혼합되어 있거나(ASC/DESC) 계산 필드가 사용되면 인덱스가 사용되지 않을 수 있습니다.

일반적인 오류 및 안티 패턴

COLLATE를 지정하지 않으면 개발자는 서버의 다양한 언어 설정에서 서로 다른 결과를 얻습니다.
보고서의 NULL을 암묵적으로 정렬하면 여러 선택 항목의 이곳 저곳에서 빈 행이 예상치 않게 나타납니다.
인덱스가 없는/계산된 필드에 대한 거대한 ORDER BY는 자원을 낭비하므로 먼저 정렬할 필드를 인덱싱합니다.

실생활 사례

부정적인 사례

관리자가 COLLATE 없이 성으로 ORDER BY를 한 보고서를 작성했습니다. 보고서를 서로 다른 서버로 옮기면서 러시아 및 라틴 성이 서로 위치가 바뀌었고, NULL은 때로는 시작, 때로는 끝에 있었습니다.

장점:

코드 최소화. 단점:
예측할 수 없는 동작과 유지 보수의 복잡성.

긍정적인 사례

보고서에서 NULL의 순서를 NULLS FIRST/LAST로 명시하고 정렬 필드에 대한 복합 인덱스를 추가했습니다. 동작이 환경에 의존하지 않게 되었고, 쿼리 속도가 크게 향상되었습니다.