MySQL 최적화에는 세 가지 측면이 포함됩니다.
- 零下一度원래의
- 2017-05-04 16:40:261514검색
데이터베이스는 인터넷 애플리케이션에 없어서는 안될 기본 종속성이 되었습니다. 그 중 MySQL은 오픈 소스 데이터베이스로 더욱 널리 사용됩니다. 최근에는 프로젝트 프로젝트 개발에 집중하면서 더 많은 애플리케이션 개발자가 MySQL 데이터베이스를 더 잘 사용할 수 있도록 개발 과정에서 사용되는 몇 가지 데이터베이스 최적화 원칙을 요약했습니다.
MySQL의 최적화에는 크게 세 가지 측면이 있습니다. 첫 번째는 SQL 문 최적화이고, 두 번째는 테이블 구조 최적화 이는 주로 인덱스 최적화를 의미하며 마지막으로 서버 구성 최적화를 의미합니다.
1. SQL문 최적화문
1) 질의문은 먼저 Full Table Scan을 피하도록 노력해야 합니다. Where 절과 OrderBy 절에 인덱스를 구축하는 것을 고려해보세요. 그러나 각 SQL 문은 최대 하나의 인덱스만 사용하며 너무 많은 인덱스를 생성하면 삽입 및 업데이트 중에 오버헤드가 발생합니다. 동시에 구별이 거의 없는 필드의 경우 인덱스 생성을 피해야 합니다. SQL을 보려면 쿼리 문 앞에 explain 키워드를 사용할 수 있습니다. 문이 인덱스를 사용하는지 확인하기 위한 실행 계획입니다. 🎜>NOT EXIST IN
및NOT IN을 바꾸세요. 후자는 전체 테이블 스캔에서 인덱스 사용을 포기할 가능성이 높기 때문입니다. 3) Where 절의 필드에 대한 NULL 판단을 피해야 합니다. > 판단은 전체 테이블 스캔으로 이어집니다.
4) 또는을 사용하지 않도록 해야 합니다. 🎜>Where 절은 전체 테이블 스캔으로 이어지기 때문에 5) 은
Where 조항!= 또는 <> 연산자도 전체 테이블 스캔을 발생시킵니다. 6) like “%abc%” 또는 like “%abc”를 사용하면 전체 테이블 스캔이 발생하지만 like “ abc%”는 인덱스를 사용합니다. 7) Union 연산자를 사용할 때는 Union ALL을 대신 사용할 수 있는지 고려해야 합니다. Union 연산자가 결과에 대해 정렬 작업을 수행하고 중복 레코드를 삭제할 때 이 요구 사항이 없는 애플리케이션에는 Union ALL을 사용해야 합니다. 후자는 결과만 병합하고 8) 은 Where 절에 표현식 연산자를 사용하지 않도록 노력해야 합니다. 전체 테이블 스캔 9) Where 절의 필드에 함수를 사용하지 않는 것이 좋습니다. 원인 전체 테이블 스캔 10) 선택 시도 "*" 사용을 피하세요. , SQL 문의 구문 분석 과정에서 "*"이 모든 컬럼의 컬럼명으로 변환되기 때문에 이 작업은 데이터 사전을 질의함으로써 완료되기 때문에 특정 오버헤드 11) Where 절에서는 Where 절은 뒤에서 앞으로 이므로 Where 절 끝에 대부분의 레코드를 필터링할 수 있는 제한 사항을 넣어보세요. 12) 데이터베이스 테이블에 index(a,b,c)와 같은 결합 인덱스가 있는 경우 절의 조건 필드가 나타나는 순서 인덱스 필드의 표시 순서와 동일해야 합니다. 그렇지 않으면 공동 인덱스를 사용할 수 없습니다. 13) From 필드의 테이블 표시 순서. 절은 SQL 문의 순서에도 영향을 미치며, 절은 뒤에서 앞으로 구문 분석됩니다. 레코드 수가 적은 테이블을 기본 테이블로 선택하여 마지막에 배치해야 합니다. 3 테이블 연결 쿼리가 있는 경우에는 십자가 테이블을 기본 테이블로 사용해야 합니다. 14) > 연산자 대신 >= 연산자를 사용해 보세요. 예를 들어 다음 SQL 명령문, select dbInstanceIdentifier from DBInstance where id > 3, 이 명령문은 select dbInstanceIdentifier from DBInstance where id >=4 로 대체되어야 합니다. 두 명령문의 실행 결과는 다음과 같습니다. 동일하지만 성능이 다릅니다. 전자가 실행될 때 먼저 3과 동일한 레코드를 찾은 다음 앞으로 스캔하고 후자는 동일한 레코드를 직접 찾기 때문에 후자가 더 효율적입니다. 4으로. 2. 테이블 구조 최적화 주로 인덱스를 올바르게 생성하는 방법을 말합니다. 인덱스를 무리하게 사용하면 전체 쿼리로 이어지기 때문입니다. 테이블 스캔 및 인덱스가 너무 많으면 삽입 및 업데이트에 대한 성능 오버헤드가 발생합니다. 우선 각 항목을 확인하세요. isclear SQL 문은 최대 하나의 인덱스만 사용할 수 있습니다. 사용할 수 있는 인덱스가 여러 개인 경우 시스템은 실행 비용을 기준으로 실행할 인덱스를 선택합니다. >2) Innodb 자동으로 생성된 기본 키 열에 여러 문제가 있습니다. 1. 성능이 부족하여 캐시를 사용하여 읽을 수 없습니다. 모든 테이블에 기본 키가 없습니다. 시스템은 전역 Auto_Increment 열을 공유합니다. 따라서 InnoDB의 모든 테이블은 테이블 생성 시 기본 키를 지정해야 합니다. 3) 4) 하나의 필드에 대한 인덱스만 생성하면 됩니다. 고유 인덱스를 생성하고 INDEX 5) 큰 텍스트 필드 또는 BLOB 6) 연결 쿼리의 연결 필드를 색인화해야 합니다. 7) 일반적으로 정렬 필드를 색인화해야 합니다. ; 8) 일반적으로 그룹 통계 필드를 색인화해야 합니다. 9) 조인트 인덱스를 올바르게 사용하세요. 조인트 인덱스의 첫 번째 필드는 단독으로 사용할 수 있습니다. 예를 들어 다음 조인트 인덱스 index(userID,dbInstanceID), 다음 쿼리 문에서 이 인덱스를 사용할 수 있습니다. select userID=?인 DBInstance의 dbInstanceIdentifier, 그러나 select dbInstanceIdentifier from DBInstance where dbInstanceID=?는 이 인덱스를 사용할 수 없습니다. 인덱스는 일반적으로 레코드가 많은 테이블에 사용됩니다. DBInstance 테이블이 있는 경우 모든 쿼리에는 userID 조건 필드가 있는 것으로 현재 알려져 있습니다. 즉, 각 쿼리는 하나의 userID에 대한 레코드가 많지 않기 때문에 테이블은 userID에만 인덱스를 생성하면 됩니다. 각 userID에 해당하는 레코드 데이터가 많지 않기 때문에 다른 필드를 인덱싱하지 않아도 기본적으로 영향이 없습니다. 동시에 너무 많은 인덱스 설정으로 인해 발생하는 삽입 및 업데이트 성능 오버헤드가 발생할 수 있습니다. ． MySQL서버 구성 최적화 1) MySQL 서버에는 특정 시간 간격을 초과하는 쿼리 문을 기록할 수 있는 느린 연결 로그가 있으며, 개발자 추적을 용이하게 하기 위해 인덱스를 사용하지 않습니다. slow_query_log=ON/을 설정하여 느린 연결 로그 기능을 켜거나 끌 수 있습니다. OFF slow_query_log_file 느린 접속 로그 파일명 설정, long_query_time 타임아웃 설정, 단위는 ms,느린 접속에 주의하세요. 로그MySQL은 기본적으로 꺼져 있습니다. 2) MySQL 에는 쿼리 캐시 기능이 있습니다. 동일한 쿼리로 인해 발생하는 서버 오버헤드를 줄이기 위해 서버는 쿼리 문과 해당 반환 결과를 저장합니다. query_cache_size 캐시 크기 0은 쿼리 캐시를 끄는 것을 의미하지만 테이블이 업데이트되면 모든 쿼리 캐시가 기본적으로 MySQL 3) max_connections를 구성하여 데이터베이스에 대한 최대 연결 수를 설정할 수 있습니다. >wait_timeout 최대 연결 수 설정 긴 보존 시간, 시간 단위는 초, MySQL 기본값은 8시간, 8을 초과하면 시간이 지나면 데이터베이스가 자동으로 연결을 끊습니다. 이는 연결 풀의 연결이 서버에 의해 끊어졌을 수 있으므로 데이터베이스 연결 풀을 사용할 때 주의가 필요합니다. 애플리케이션이 연결 풀에서 연결을 가져와 이를 사용할 때 오류가 발생합니다. max_connect_errors애플리케이션에서 여러 예외가 발생하면 데이터베이스에 대한 호스트 연결이 종료됩니다. 【관련 추천】
위 내용은 MySQL 최적화에는 세 가지 측면이 포함됩니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!