문화권에 따라 데이터 정렬이 다른 경우 문자열 열에 대해 ORDER BY를 효율적으로 수행하는 방법은 무엇입니까? 즉, 다른 문화권의 사용자에 대한 데이터는 동일한 테이블과 동일한 열에 저장되지만 각 사용자는 자연스럽게 로케일에 따라 정렬 된 것을 보려고합니다 (로케일은 물론 테이블의 각 행마다 고정되고 고정되어 있음). 그리고 테이블은 매우 길 수 있으므로 컬럼 요구와 색인이 필요하며 응용 프로그램 측에서 원하는 데이터 정렬로 후 처리 할 수 없습니다 (엄청난 양의 작업을 수행하는 데이터베이스 작업입니다).동일한 MariaDB 열에 대한 여러 데이터 정렬?
예를 들어 utf8_general_ci
은 utf8_swedish_ci
과 다른 결과를 생성합니다.
문제는 모든 국제 프로젝트에서 분명해야한다고 생각하지만, 적절한 솔루션을 찾을 수는 없습니다. 나 자신은 그 좋은하지 만 다음과 같은 솔루션을 이미징 할 수 있고 더 나은 아무것도 할 수 없습니다 의심 :
- 는보기는 문화별로 생성 및 인덱싱 할 수
- 어쩌면 각 조합에 대해 별도의 필드를 사용하여 따라서 하나의 정렬 문자열 열이 있다면
- 는
이제, 단지 정렬 어쩌면 가상 별도의 "대리"필드를 사용하여 (그래도 난 MariaDB의 전망 근무 한 적이없는, 그래서 이것은 매우 이론적 인) 그러나 몇 가지있을 수 있습니다. 이것을 해결하기위한 의도와 올바른 방법은 무엇입니까?
는
이 "작은"테이블 괜찮 다음
ORDER
절에여러 열은 각각 자신의
COLLATE
용어를 얻을. 'COLLATE' 절을 붙이면 인덱스가 이미 특정 데이터 정렬에 있으므로'INDEX'를 사용할 수 없습니다. –아 맞습니다. 'COPLATE' 절에서 다른 데이터 정렬을 사용할 때'EXPLAIN'은 "filesort를 사용하여 인덱스 사용"을 말합니다. 음, 그렇다면 원하는 데이터 정렬에서 관련 열을 복제하는 방법을 찾아내는 데 필요한 노력을 최소화해야합니다. 가상 컬럼은 영구적 인 컬럼 인'INDEX'를 얻을 수 없기 때문에 여기서는 도움이되지 않지만'EXPLAIN'은 항상'SELECT'에서 파일 정렬을 사용한다고 말합니다. 따라서 원하는 열을 수동으로 추가 열에 채울 수 있습니다. 흠, 아주 안좋아. – Anse
Filesort는 여러 가지 이유로 발생합니다. 특정 쿼리를 살펴보고 그것에 대해 논의하는 CREATE TABLE을 보겠습니다. –