지난 한 주 동안 int를 varchar로 변환할 때 index를 사용할 수 없어 느린 쿼리 2개를 차례로 처리했습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
appkey가 varchar이고 where 조건에 ''를 추가하지 않았기 때문에 추가되면 전체 테이블 쿼리가 실행된다는 것을 위에서 분명히 알 수 있습니다. , 인덱스를 사용할 수 있습니다. 스캔되는 행 수가 매우 다르며 서버에 대한 부담과 응답 시간도 매우 다릅니다.
다른 예를 살펴보겠습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
위 예에서는 poll_id 유형이 bigint이지만 SQL에 ''가 추가됩니다. 이 명령문은 여전히 인덱스를 사용합니다. 스캔할 행이 많지만 인덱스를 사용하는 것이 좋은 SQL입니다.
이렇게 작은 ''가 왜 이렇게 큰 영향을 미치는 걸까요? 근본적인 이유는 MySQL이 텍스트 유형과 숫자 유형을 비교할 때 암시적 유형 변환을 수행하기 때문입니다.
5.5 공식 매뉴얼 설명은 다음과 같습니다.
1 2 3 4 5 6 7 8 9 10 11 |
|
위 설명에 따르면 where 조건 뒤의 값의 종류가 다음과 같을 때 테이블 구조와 일치하지 않는 MySQL은 암시적 유형 변환을 수행하고 비교를 위해 이를 부동 소수점 숫자로 변환합니다.
첫 번째 경우:
예: string = 1;
인덱스의 문자열을 부동 소수점 숫자로 변환해야 합니다. 하지만 '1',' 1','1a'는 모두 1로 변환되므로 MySQL은 인덱스를 사용할 수 없고 전체 테이블 스캔만 수행할 수 있어 쿼리 속도가 느려집니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
동시에, 비교를 위해 부동 소수점 숫자로 변환되며, 부동 소수점 숫자는 최대값을 초과하는 경우 53비트에 불과하므로 주의해야 합니다. , 비교에 문제가 발생합니다.
두 번째 경우:
인덱스가 int 기반이므로 순수 숫자열은 100% 숫자로 변환이 가능하므로 인덱스를 사용할 때 , 특정 변환이 수행되고 특정 리소스가 소비되지만 결국 인덱스는 계속 사용되며 느린 쿼리는 발생하지 않습니다.
위 내용은 MySQL 데이터베이스에서 int 유형을 varchar 유형으로 변환하면 쿼리가 느려지는 문제가 발생합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!