관련 학습 권장 사항: mysql 튜토리얼
오늘 야근을 했는데 판매원이 데이터를 확인하러 우리에게 와서 데이터가 틀렸다. 그 여자의 SQL이 다음과 같이 쓰여 있는 것을 봤습니다.
select distinct * from prvt_pub_stmt_vnwhere issue_time >= '2020-08-01'and issue_time <= '2020-08-01'and prs_dmtd_cde in ('p','n');复制代码
분석한 결과 문제가 없는 것으로 확인되어 prs_dmtd_cde 필드의 코드 값을 확인해 보니 대문자 P뿐만 아니라 소문자 p도 있는 것으로 나타났으나, 소녀는 확인만 했습니다. 소문자 p가 없으면 데이터의 양이 훨씬 더 많습니다.
그래서 소녀의 SQL을 변경했습니다:
select distinct * from prvt_pub_stmt_vnwhere issue_time >= '2020-08-01'and issue_time <= '2020-08-01'and prs_dmtd_cde in ('p','n','P','N');复制代码
결과는 동일했습니다. 그게 다야. . .
물론 여자 앞에서는 안된다고 할 수 없으니 돌아가서 구경해보라고 했어요.
빠르게 온라인으로 확인해 보니 MySQL의 인코딩 형식과 정렬 규칙에 문제가 있는 것으로 나타났습니다.
MySQL 데이터베이스는 기본적으로 utf8 인코딩 형식을 사용하며, utf8 인코딩 형식에는 다양한 정렬 규칙이 있습니다. 일반적으로 사용되는 것은 다음과 같습니다.
utf8_bin: 문자열의 각 문자를 대소문자를 구분하여 16진수 데이터로 저장합니다.
utf8_general_ci: 대소문자를 구분하지 않음, ci는 대소문자를 구분하지 않음, 즉 대소문자를 구분하지 않음의 약어입니다.
기본 문자 집합 설정을 다시 확인하세요.
utf8 인코딩 형식의 기본 정렬 규칙은 utf8_general_ci입니다. 즉, 대소문자를 구분하지 않습니다.
문제의 원인이 발견되면 올바른 치료법을 처방해드릴 수 있습니다.
해결책은 당연히 필드의 대조 속성을 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 >= '2020-08-01'and issue_time <= '2020-08-01'and binary prs_dmtd_cde in ('p','n');复制代码
Mysql 기본 쿼리는 대소문자를 구분하지 않습니다. SQL 문에 바이너리를 추가하여 대소문자를 구분할 수 있습니다.
바이너리는 함수가 아니지만, 뒤에 오는 문자열을 강제로 바이너리 문자열로 만드는 데 사용됩니다. 문자열 비교 시 대소문자를 구분하는 것으로 이해될 수 있습니다.
문제가 해결되었습니다. 물론 나는 그 소녀에게 문제가 얼마나 심오한지, 어떻게 원리를 분석하고 마침내 해결했는지 이야기했습니다.
소녀의 사랑스러운 표정을 보니 당연히 매우 행복합니다.
가장 중요한 것은 이 문제를 기억하는 것입니다. 앞으로 필드가 대소문자를 구분하는 비즈니스 사례를 접하게 되면 이러한 일이 발생하지 않도록 테이블을 작성할 때 문자 집합 선택 및 정렬 규칙에 주의해야 합니다. 오늘.
프로그래밍 학습에 대해 더 자세히 알고 싶다면 php training 칼럼을 주목해주세요!
위 내용은 MySQL의 where 쿼리에 대한 재이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!