Mysq에 대한 몇 가지 일반적인 오해

일반적인 오해

1. count(1)와 count(primary_key)가 count(*)보다 낫습니다

많은 사람들이 숫자를 세는 데 count 대신 count(1)과 count(primary_key)를 사용합니다. (*), 그들은 이것이 더 나은 성능을 발휘한다고 생각하지만 실제로는 오해입니다. 일부 시나리오에서는 데이터베이스가 count(*) 계산 작업에 대해 특별한 최적화를 수행했기 때문에 이로 인해 성능이 저하될 수 있습니다.

1. count(열)과 count(*)는 동일합니다

이러한 오해는 많은 수석 엔지니어나 DBA 사이에서도 흔히 발생하며, 많은 사람들이 이를 당연하게 여깁니다. 사실 count(column)와 count(*)는 전혀 다른 연산이고, 전혀 다른 의미를 갖고 있습니다.

count(column)는 열 필드가 비어 있지 않은 결과 집합의 레코드 수를 의미합니다.

count(*)는 전체 결과 집합에 있는 레코드 수를 의미합니다.

1. select a,b from ...은 a,b,c from...을 선택하는 것보다 낫습니다. 데이터베이스가 더 적은 양의 데이터에 액세스할 수 있도록 허용할 수 있습니다

이러한 오해는 주로 많은 개발자들 사이에 존재합니다. 데이터베이스의 저장 원리에 대해 많이 설명합니다.

실제로 대부분의 관계형 데이터베이스는 행에 저장되며, 데이터 액세스 작업은 일반적으로 4KB인 고정 크기 IO 단위(블록 또는 페이지라고 함)를 기반으로 합니다. 대부분의 경우 여러 행이 저장됩니다. 각 IO 유닛과 각 행은 해당 행의 모든 ​​필드를 저장합니다(lob과 같은 특수 유형 필드 제외).

따라서 하나의 필드를 사용하든 여러 필드를 사용하든 데이터베이스가 테이블에서 액세스해야 하는 데이터의 양은 실제로 동일합니다.

물론 예외가 있습니다. 즉, 쿼리는 인덱스에서 완료될 수 있습니다. 즉, 두 개의 필드 a와 b만 가져온 경우 테이블을 반환할 필요가 없으며 필드 c는 다음과 같습니다. 사용된 인덱스에 없습니다. 해당 데이터를 얻으려면 테이블로 돌아가야 합니다. 이 경우 둘 사이의 IO 볼륨은 상당히 다릅니다.

1. order by에는 정렬 작업이 필요합니다.

필요한 데이터가 인덱스와 동일한 순서이고 쿼리가 실행되면 이 인덱스를 통과하는 경우 인덱스 데이터가 실제로 정렬된다는 것을 알고 있습니다. , 데이터베이스는 일반적으로 정렬 작업을 생략하고 데이터를 직접 반환합니다. 왜냐하면 데이터베이스는 데이터가 이미 정렬 요구 사항을 충족한다는 것을 알고 있기 때문입니다.

실제로 정렬 요구 사항을 갖춘 SQL을 최적화하기 위해 인덱스를 사용하는 것은 매우 중요한 최적화 방법입니다

확장 읽기: MySQL ORDER BY 구현 분석, MySQL의 GROUP BY 기본 구현 원리, MySQL의 기본 구현 원리 DISTINCT This 3 이번 글에는 좀 더 심층적인 분석이 있는데, 특히 첫 번째 글에는

1. filesort가 실행 계획에 포함되면 디스크 파일이 정렬됩니다

사실 이런 오해는 우리 잘못은 아니지만 MySQL 개발 때문에 저자는 표현에 문제가 있습니다. filesort는 explain 명령을 사용하여 SQL 문의 실행 계획을 볼 때 "Extra" 열에 표시되는 정보입니다.

실제로 SQL 문에 정렬 작업이 필요할 때마다 "Using filesort"가 표시되지만 이는 파일 정렬 작업이 있다는 의미는 아닙니다.

더 읽어보기: MySQL explain 명령 출력의 파일 정렬 이해, 여기에 더 자세한 소개가 있습니다

• 기본 원칙

1. 가능한 적은 수의 조인

MySQL의 장점은 단순성입니다. , 그러나 이것은 실제로 어떤 측면에서는 단점입니다. MySQL 옵티마이저는 매우 효율적이지만 제한된 통계 정보로 인해 옵티마이저의 작업 프로세스에서 편차가 발생할 가능성이 더 큽니다. 복잡한 다중 테이블 Join의 경우 제한된 최적화로 인해 Join에 대한 노력이 부족하여 Oracle과 같은 이전 관계형 데이터베이스에 비해 성능이 여전히 크게 뒤떨어집니다. 그러나 단순한 단일 테이블 쿼리인 경우 일부 시나리오에서는 이 격차가 매우 작으며 이전 데이터베이스보다 훨씬 더 좋습니다.

1. 가능한 한 적게 정렬

정렬 작업은 더 많은 CPU 리소스를 소비하므로 정렬을 줄이면 캐시 적중률이 높고 IO 기능이 충분한 시나리오에서 SQL의 응답 시간에 큰 영향을 미칠 수 있습니다.

MySQL의 경우 다음과 같이 정렬을 줄이는 방법이 많이 있습니다.

• 인덱스를 사용하여 정렬하여 위의 오해를 최적화

• 정렬에 참여하는 레코드 수를 줄입니다.

• 필요한 경우가 아니면 데이터를 정렬하지 마세요

• 리소스를 소모하는 작업, DISTINCT가 포함된 SQL 문 사용을 피하세요. UNION, MINUS, INTERSECT, ORDER BY는 리소스 소비 정렬(SORT) 기능을 실행하기 위해 SQL 엔진을 시작합니다. DISTINCT에는 한 번의 정렬 작업이 필요하지만 다른 경우에는 적어도 두 번의 정렬 작업이 필요합니다

위 내용은 Mysq에 대한 몇 가지 일반적인 오해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!