어제 MySQL에서 영숫자 정렬을 해결하려고 시도했지만 실패했습니다. (여기서 해당 기사를 읽어보세요)
친해지기는 했지만 컨셉은 맞았고 실행은 잘못됐을 뿐입니다.
오늘 일어났더니 깨달음이...재귀였습니다.
재귀의 문제는 재귀를 이해해야 재귀를 할 수 있다는 점인데...저는 MySQL에서 재귀를 할 만큼 재귀를 이해하지 못합니다.
그러나 약간의 Chat Gippity가 왔다 갔다 합니다(즉, 내가 요청한 내용을 작성하도록 하고, 요청한 내용의 약 25%를 돌려받고, 수정한 후 새 채팅에 입력하여 2시간 정도 계속 반복하지 마세요) 작동하는 답변을 얻었습니다!
나의 백조의 노래, 나의 걸작, 삶 자체에 대한 답을 여러분께 소개하겠습니다(알겠습니다. 제가 본 MySQL의 진정한 영숫자 정렬에 대한 유일한 작동 솔루션입니다).
WITH RECURSIVE process_numbers AS ( SELECT data_value, data_value AS remaining_data, CAST('' AS CHAR(20000)) AS processed_data, 1 AS iteration FROM test_data UNION ALL SELECT data_value, CASE WHEN LOCATE(REGEXP_SUBSTR(remaining_data, '[0-9]+'), remaining_data) > 0 THEN SUBSTRING( remaining_data, LOCATE(REGEXP_SUBSTR(remaining_data, '[0-9]+'), remaining_data) + LENGTH(REGEXP_SUBSTR(remaining_data, '[0-9]+')) ) ELSE '' END AS remaining_data, CONCAT( processed_data, CASE WHEN LOCATE(REGEXP_SUBSTR(remaining_data, '[0-9]+'), remaining_data) > 0 THEN LEFT(remaining_data, LOCATE(REGEXP_SUBSTR(remaining_data, '[0-9]+'), remaining_data) - 1) ELSE remaining_data END, CASE WHEN REGEXP_SUBSTR(remaining_data, '[0-9]+') IS NOT NULL THEN RIGHT(CONCAT('0000000000', REGEXP_SUBSTR(remaining_data, '[0-9]+')), 10) ELSE '' END ) AS processed_data, iteration + 1 FROM process_numbers WHERE LENGTH(remaining_data) > 0 AND iteration < 100 ) SELECT data_value, CONCAT(processed_data, remaining_data) AS sort_key FROM process_numbers WHERE remaining_data = "" ORDER BY sort_key;
그리고 그것을 시험해 보고 싶다면(그리고 부수고 싶다면) 이 DB 바이올린을 가지고 놀 수 있습니다
제가 원래 원했던 작업을 수행합니다. 모든 숫자 그룹을 가져와서 총 10자리로 채웁니다.
따라서 11개의 연속 숫자가 포함된 두 개의 문자열을 입력하면 분명히 조정 없이는 작동하지 않지만 그 외에는 잘 작동합니다!
MySQL은 사전순 정렬 모드에서도 숫자를 올바르게 정렬할 수 있지만 한 가지 결함이 있습니다.
한 번에 한 문자씩 (효과적으로) 정렬하므로 "11"은 "2"보다 작은 것으로 계산됩니다. 따라서 "2"는 "1"보다 크므로 먼저 옵니다. 그런 다음 정렬이 잘못된 지점에서 다음 문자를 확인합니다(적어도 숫자의 경우).
이를 더 잘 이해하려면 1이 실제로 문자 "b"이고 2가 문자 "c"라고 상상해 보세요.
이것이 MySQL이 숫자를 "보는" 방식이며, 숫자는 단지 또 다른 문자일 뿐입니다.
그래서 "bb"와 "c"가 있다면 "bb"가 "c" 앞에 올 것이라고 기대할 것입니다. 이제 숫자를 다시 바꾸면 "11"이 "2" 앞에 오는 이유를 알 수 있습니다.
예, 패딩을 통해 숫자를 "뒤로" 이동하여 문제를 제거합니다.
예로 돌아가서 "11"과 "2"를 3으로 채우고 "a"를 0으로 사용하면 다음과 같은 일이 발생합니다.
011 = abb 002 = aac
이제 정렬이 어떻게 진행되는지 확인하세요.
이제 논리에 따르면 다음과 같습니다.
002 = aac (the second "a" comes before the second "b" in the next row) 011 = abb
이것이 바로 작동 방식입니다!
그런데요. 나는 이것으로 "집안을 돌아다녔"고 내 지식은 표면적 수준이지만 시도해 보겠습니다.
문제는 RegEx가 MySQL에서 작동하는 방식에 발생했습니다. REGEX_SUBSTR은 일치하는 항목을 하나만 찾은 다음 찾은 다른 모든 일치 항목에 대해 해당 항목을 계속 반환합니다. 그래서 어제의 솔루션이 제대로 작동하지 않았던 것입니다.
하지만 REGEX_REPLACE에는 일치 항목의 문자열 길이를 올바르게 노출하지 않는 것 같은 자체 문제가 있습니다(따라서 이를 올바르게 LPAD할 수 없음)
그래서 저는 재귀를 그 답으로 생각했습니다.
REGEX_SUBSTR을 사용하여 올바른 패딩 동작을 얻을 수 있으며 RegEx를 통한 각 루프는 본질적으로 새로운 함수 호출이므로 이전 일치 항목을 "기억"하지 않으므로 문제가 해결됩니다.
그리고 논리를 간략하게 살펴보고 싶다면 실제로는 보이는 것만큼 무섭지 않습니다!
그런 다음 쿼리에서 이 sort_key를 사용하여 열을 올바르게 정렬할 수 있습니다.
그리고 반복 부분은 MySQL 서버의 메모리 부족을 완전히 실행하지 않거나 충분히 복잡한 문자열이 처리되는 경우(또는 의미하는 논리에 오류가 있는 경우) 쿼리가 중단되지 않도록 하는 순전히 보호 도구입니다. 영원히 반복됩니다).
잠을 자는 것이 새로운 관점을 가져오는 것이 재미있지 않나요?
아마도 매일 2~3배 더 자주 문제에 대해 잠을 잘 수 있고 10배의 개발자가 될 수 있도록 다상 수면을 시도해야 할까요? 하하.
어쨌든 합리적으로 견고한 참 영숫자 정렬
이 있습니다.아, 실제로는 GENERATE 또는 저장 프로시저를 사용하여 sort_key를 데이터베이스의 저장 열로 변환해야 할 것입니다. 아쉽게도 제가 이용하는 놀이터에서는 지원하지 않는 것 같은데, 일요일이라 이 부분은 시청자 여러분께 맡기겠습니다!
남은 주말 잘 보내시고, 즐거운 한 주 보내세요.
위 내용은 MySQL의 진정한 영숫자/자연 정렬 - 왜 대답은 항상 재귀입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!