안 된다고 말할 수 없습니다

오늘 야근을 했는데 판매원이 데이터를 확인하러 우리에게 와서 데이터가 틀렸다. 그 여자의 SQL이 다음과 같이 쓰여 있는 것을 봤습니다.

select distinct * from prvt_pub_stmt_vnwhere issue_time >= &#39;2020-08-01&#39;and issue_time <= &#39;2020-08-01&#39;and prs_dmtd_cde in (&#39;p&#39;,&#39;n&#39;);复制代码

로그인 후 복사

분석한 결과 문제가 없는 것으로 확인되어 prs_dmtd_cde 필드의 코드 값을 확인해 보니 대문자 P뿐만 아니라 소문자 p도 있는 것으로 나타났으나, 소녀는 확인만 했습니다. 소문자 p가 없으면 데이터의 양이 훨씬 더 많습니다.

그래서 소녀의 SQL을 변경했습니다:

select distinct * from prvt_pub_stmt_vnwhere issue_time >= &#39;2020-08-01&#39;and issue_time <= &#39;2020-08-01&#39;and prs_dmtd_cde in (&#39;p&#39;,&#39;n&#39;,&#39;P&#39;,&#39;N&#39;);复制代码

로그인 후 복사

결과는 동일했습니다. 그게 다야. . .

물론 여자 앞에서는 안된다고 할 수 없으니 돌아가서 구경해보라고 했어요.

빠르게 온라인으로 확인해 보니 MySQL의 인코딩 형식과 정렬 규칙에 문제가 있는 것으로 나타났습니다.

이유를 알아보세요

MySQL 데이터베이스는 기본적으로 utf8 인코딩 형식을 사용하며, utf8 인코딩 형식에는 다양한 정렬 규칙이 있습니다. 일반적으로 사용되는 것은 다음과 같습니다.

utf8_bin: 문자열의 각 문자를 대소문자를 구분하여 16진수 데이터로 저장합니다.

utf8_general_ci: 대소문자를 구분하지 않음, ci는 대소문자를 구분하지 않음, 즉 대소문자를 구분하지 않음의 약어입니다.

기본 문자 집합 설정을 다시 확인하세요.

utf8 인코딩 형식의 기본 정렬 규칙은 utf8_general_ci입니다. 즉, 대소문자를 구분하지 않습니다.

Solution

문제의 원인이 발견되면 올바른 치료법을 처방해드릴 수 있습니다.

해결책은 당연히 필드의 대조 속성을 utf8_bin으로 직접 수정하는 것입니다.

ALTER TABLE prvt_pub_stmt_vn CHANGE prs_dmtd_cde prs_dmtd_cde VARCHAR(255) 
CHARACTER SET utf8 COLLATE utf8_bin;复制代码

로그인 후 복사

원래 테이블 구조를 변경하는 것이 아니라 SQL을 변경하는 또 다른 해결 방법이 있습니다. 쿼리 필드 앞에 바이너리 키워드를 추가합니다.

select distinct * from prvt_pub_stmt_vnwhere issue_time >= &#39;2020-08-01&#39;and issue_time <= &#39;2020-08-01&#39;and binary prs_dmtd_cde in (&#39;p&#39;,&#39;n&#39;);复制代码

로그인 후 복사

Mysql 기본 쿼리는 대소문자를 구분하지 않습니다. SQL 문에 바이너리를 추가하여 대소문자를 구분할 수 있습니다.

바이너리는 함수가 아니지만, 뒤에 오는 문자열을 강제로 바이너리 문자열로 만드는 데 사용됩니다. 문자열 비교 시 대소문자를 구분하는 것으로 이해될 수 있습니다.