MySQL 성능 최적화로 데이터베이스 실행 속도 향상

데이터베이스 최적화 작업에서는 테이블이 큰 공간을 차지하도록 데이터를 최대한 작게 만듭니다. 공간을 가능한 한 작게 유지하는 것은 가장 일반적으로 사용되는 가장 효과적인 방법 중 하나입니다. 데이터가 줄어들기 때문에 하드 디스크의 읽기 및 쓰기 속도가 상대적으로 향상될 수 있으며 쿼리 프로세스 중 작은 테이블의 콘텐츠 처리는 시스템 리소스를 덜 차지합니다. 마찬가지로 인덱스가 더 작은 열에 설정되면 인덱스가 차지하는 리소스도 줄어듭니다. 그렇다면 데이터베이스 관리자는 어떻게 자신의 데이터에 대한 무게를 줄일 수 있습니까? 저자는 이에 대해 다음과 같은 제안을 합니다.

제안 1: Null 값이 반드시 공간을 차지하지는 않습니다

여기서 먼저 약간의 읽기 능력을 알려드리겠습니다. 일부 데이터베이스 관리자는 null 값이 시스템 리소스를 차지하지 않을 것이라고 생각합니다. 사실 이는 잘못된 이해입니다. 데이터베이스를 설계할 때 필드 속성을 NOT NULL로 설정하는 것을 좋아하지 않습니다. 사용자가 필요에 따라 데이터를 입력할 수 있습니다. 저자는 이러한 접근 방식이 데이터베이스 성능에 해롭다고 생각합니다

가능하다면 열을 NOT NULL로 설정해 보세요. 즉, null 값이 허용되지 않습니다. 이렇게 하면 후속 처리 속도가 빨라지는 동시에 데이터 저장 측면에서 열당 1비트가 절약되어 데이터 경량화 목적을 달성할 수 있습니다. 실제 작업에서 사용자가 데이터를 입력할 필요가 없는 상황이 있는 경우 비어 있지 않은 목적을 달성하기 위해 기본 필드를 사용할 수도 있습니다. 예를 들어 급여 시스템에서 사용자의 근무 연도는 기본적으로 공백이 아닌 0으로 설정될 수 있습니다. 물론, 정말로 NULL이 필요한 경우에는 방법이 없습니다. 그러나 데이터베이스 엔지니어로서 NULL 값을 사용하지 않도록 노력해야 합니다.

제안 2: 가능한 한 작은 데이터 유형을 사용하세요.

데이터 유형의 크기는 기본 테이블의 크기에도 영향을 미칩니다. 예를 들어 MEDIUMINT 및 INT 두 데이터 유형을 사용하여 정수 데이터를 저장할 수 있지만 저장할 수 있는 정밀도는 다릅니다. 하지만 데이터 저장 측면에서 전자는 후자에 비해 약 25% 정도 적은 저장 공간을 필요로 한다. 이러한 이유로 MEDIUMINT를 사용할 수 있는 경우 INT를 사용하지 마십시오.

또한 데이터 길이를 정의할 때 요구사항을 충족하면서 최대한 짧아야 합니다. 예를 들어, 급여 평가 시스템에는 직원 코딩 필드가 있습니다. 기업 사원 코드가 결정된 경우 5자로 구성됩니다. 그러면 필드를 정의할 때 길이를 5자만 정의하면 됩니다. 이는 저장 공간을 줄일 수 있을 뿐만 아니라 특정 데이터 교정 기능도 수행할 수 있습니다. 사용자가 입력한 코드 길이가 5자리를 초과하면 데이터를 저장할 수 없습니다.

특정 데이터를 저장할 때 선택할 수 있는 데이터 유형은 많지만 비교적 많은 수의 문자를 정의할 수도 있습니다. 그러나 가능한 한 가장 작은 데이터 유형을 선택하면 데이터 저장 공간을 줄이고 데이터 경량화 목적을 달성하는 데 도움이 될 수 있습니다. 이를 통해 데이터베이스 성능이 더욱 향상됩니다.

제안 3: 인덱스와 데이터 테이블 크기의 관계

글쓴이는 상대적으로 작은 열에 인덱스를 설정하면 인덱스가 리소스를 덜 차지한다고 글 초반에 언급했습니다. 인덱스는 데이터 테이블의 크기와도 밀접한 관련이 있음을 알 수 있다. 적절한 인덱스를 적절한 장소와 적절한 시기에 설정하는 것도 데이터 체중 감량의 목적을 달성할 수 있습니다.

평소와 마찬가지로 각 데이터 테이블에는 여러 개의 인덱스가 있을 수 있지만 기본 인덱스는 하나만 있는 경우가 많습니다. 이러한 이유로 각 테이블의 기본 인덱스는 최대한 짧고 간결하게 유지되어야 합니다. 이는 데이터베이스가 이를 더 빠르게 식별하는 데 도움이 될 수 있습니다.

또 다른 예는 접두어를 최대한 많이 색인화하는 것입니다. 예를 들어, 현재 테이블이 있다면 특정 열에 인덱스를 설정해야 합니다. 그리고 이 열에는 특징이 있습니다. 즉, 처음 몇 글자에 고유한 접두어가 있다는 것입니다. 이런 경우에는 모든 접두사를 색인하는 것보다 이 접두사를 긴밀하게 색인화하는 것이 더 좋습니다. MySQL 데이터베이스에서는 문자 열의 가장 왼쪽 부분에 인덱스를 생성하는 기능을 지원합니다. 이는 데이터베이스가 특정 규칙에 따라 필드를 두 부분으로 분할한다는 의미입니다. 분할 후에도 앞부분의 데이터가 고유하게 유지될 수 있는 경우 앞부분에만 인덱스를 설정하면 되며 전체 필드의 데이터에 대해서는 인덱스를 설정할 필요가 없습니다. 이는 의심할 여지없이 인덱스가 차지하는 자원을 줄이고 체중 감량 목적을 달성할 수 있습니다. 인덱스가 짧을수록 쿼리 속도가 더 빨라집니다. 하드 드라이브 공간을 덜 차지하고 인덱스 캐시에 더 많은 액세스를 저장하기 때문입니다. 이렇게 하면 하드 디스크 검색 횟수가 줄어들고 쿼리 효율성이 향상됩니다.

마지막으로 주의할 점은 인덱스를 남용할 수 없다는 점입니다. 인덱스를 사용하면 실제로 데이터 처리 기능이 향상될 수 있지만 인덱스를 사용하면 추가 오버헤드도 발생합니다. 이점이 오버헤드보다 클 때만 인덱스를 사용하면 데이터베이스 성능을 향상시킬 수 있습니다. 그렇지 않으면 반대 효과가 발생합니다. 예를 들어, 테이블을 빠르게 저장해야 하는 경우, 테이블에 너무 많은 인덱스를 설정하면 인덱스에 부작용이 발생합니다. 이에 저자는 주로 검색 컬럼의 조합을 통해 테이블에 접근하는 경우에는 인덱스를 하나만 설정하는 것이 가장 좋다고 제안한다. 물론 이 인덱스 부분은 일상 업무에서 가장 일반적으로 사용되는 열이어야 합니다. 최후의 수단으로 여러 인덱스를 사용해야 하는 경우 더 많은 복사본이 있는 열을 사용하여 더 나은 인덱스 압축을 얻는 것이 가장 좋습니다. 이렇게 하면 여러 인덱스를 사용하여 발생하는 리소스 소비 증가가 줄어듭니다.

제안 4: 그래도 배불러야 할 부분은 빼놓을 수 없다

여자는 날씬해야 할 곳은 날씬해야 하고, 통통해야 할 곳은 통통해야 한다 그녀는 통통해야합니다. 실제로 데이터베이스의 경우에도 마찬가지입니다. 하드 드라이브 공간을 절약할 수 있는 곳에 저장하십시오. 그리고 살을 빼기 위해서는 절약할 수 없는 것을 합리화할 수 없습니다. 때로는 이것이 역효과를 낳을 수도 있습니다.

저자는 Varchar를 예로 든다. MyISAM과 마찬가지로 가변 길이 열이 없으면 고정 크기 데이터 유형을 사용하는 것이 좋습니다. 고정 길이 데이터 유형을 사용하더라도 일정량의 저장 공간이 낭비되는 경우가 많습니다. 사용자가 입력한 데이터가 부족하여 고정 길이를 사용하는 경우 데이터는 여전히 이 고정 길이로 저장되기 때문입니다. 하지만 이 경우 고정 길이를 사용할 수 있다면 여전히 고정 길이를 사용해야 합니다. 이 경우 일정량의 하드 디스크 공간이 낭비되더라도 데이터 쿼리 속도를 향상시킬 수 있기 때문입니다.

어떤 상황에서도 데이터의 무게 손실이 데이터베이스 성능을 향상시킬 수 없다는 것을 알 수 있습니다. 이는 비용을 절감하고 수익을 늘리는 것과 같으며 이러한 절감액은 최첨단에 저장되어야 합니다. 그렇지 않으면 돈을 절약할 수 없을 뿐만 아니라 발에 총을 쏘게 될 것입니다. 일반인의 말로는 날씬해야 할 곳은 날씬하고, 통통해야 할 곳은 통통해야 한다는 것입니다. 이 문장만 기억하세요.

제안 5: 체중 감량 목적을 위해 테이블을 나누세요

개미가 먹이를 옮길 때 먹이 조각이 너무 커서 움직일 수 없으면 개미는 움직일 수 있을 때까지 먹이 조각을 나눌 수 있습니다. 이것이 케이크를 나누는 원리입니다. 실제로 이런 현상은 일상 업무에서 흔히 볼 수 있는 현상이다. 예를 들어 데이터베이스 테이블이 있고 그 안에 레코드가 많으면 테이블에 허용되는 속도가 매우 느려집니다. 이 경우 테이블은 특정 규칙에 따라 여러 통합 문서로 나눌 수 있습니다. 예를 들어 이제 기업 직원의 출석 정보 사본이 있습니다. 이 테이블을 쿼리하고 정렬하고 계산할 때 대기 시간이 매우 깁니다. 이때 부서별로 서로 다른 워크북으로 나누어 관련 데이터 분석을 수행할 수 있습니다. 이때 작업량은 더 커지지만 처리 속도는 훨씬 빨라질 것입니다

이 원칙에 따르면 데이터베이스를 최적화할 때 자주 스캔되는 큰 테이블을 2개 이상으로 분할하여 표현할 수 있습니다. 매우 도움이 됩니다. 예를 들어 일상 업무에는 이제 동적 형식의 데이터 테이블이 있고 이 데이터가 스캔 테이블을 사용할 때 이를 사용하여 관련 행의 비교적 작은 정적 형식 테이블을 찾습니다.

이 테이블 분할을 통해 큰 케이크를 여러 개의 작은 케이크로 나누어 후속 데이터 통계 및 분석을 용이하게 할 수 있습니다. 물론, 이 효과의 품질은 이 분할 규칙과 직접적인 관련이 있습니다. 원하는 효과를 얻기 위해 테이블을 분할하는 방법과 관련하여 이는 또 다른 비교적 큰 주제입니다. 여기에서는 지면이 제한되어 있으므로 저자는 많은 설명을 하지 않을 것입니다. 아마도 후속 기사에서 저자는 이 제안을 확장하고 자세한 설명을 제공할 것입니다.

위 내용은 데이터베이스 실행 속도를 높이기 위한 MySQL 성능 최적화 내용입니다. 자세한 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!