데이터베이스 SQL 튜닝에는 어떤 방법이 있나요?-MySQL 튜토리얼-php.cn

방법: 1. 인덱스를 생성할 때 전체 테이블 스캔을 피하십시오. 2. 인덱스에 대한 계산을 사용하지 마십시오. 3. 매개변수화된 SQL을 사용하십시오. 4. 여러 SQL 문을 하나의 SQL 문으로 압축해 보십시오. HAVING 절을 대체하는 where 절을 사용하십시오. 6. 여러 테이블을 연결할 때는 테이블 별칭을 사용하십시오. 7. 커서 등을 사용하지 마십시오.

데이터베이스 SQL 튜닝에는 어떤 방법이 있나요?

이 튜토리얼의 운영 환경: windows7 시스템, mysql8 버전, Dell G3 컴퓨터.

1. 인덱스 생성

1. 전체 테이블 스캔을 방지하려면 먼저 where 및 order by와 관련된 열에 인덱스 생성을 고려해야 합니다. (1) 자주 필요한 필드에 인덱스를 생성합니다. 검색 예를 들어 테이블 필드 사용자 이름을 기준으로 검색하려면 이름 필드에 인덱스를 생성해야 합니다. 직원 부서 및 직원 직급을 기반으로 자주 검색하려면 두 필드에 인덱스를 생성해야 합니다. 직원 부서 및 직원 직급.

(2) 검색할 인덱스를 생성하면 성능이 크게 향상되는 경우가 많기 때문에 검색 속도가 너무 느리다고 판단되면 가장 먼저 생각해 봐야 할 것은 인덱스를 생성하는 것입니다.

(3) 테이블에 인덱스가 6개를 초과하지 않는 것이 가장 좋습니다. 너무 많으면 일반적으로 사용되지 않는 일부 열에 인덱스를 구축할 필요가 있는지 고려해야 합니다. 인덱스는 많을수록 좋습니다. 인덱스는 해당 선택의 효율성을 향상시킬 수 있지만 삽입이나 업데이트 중에 인덱스가 다시 작성될 수 있으므로 삽입 및 업데이트의 효율성도 감소하므로 인덱스 구축 방법에 주의해야 합니다. 구체적인 상황에 따라 고려됩니다.

2. 인덱스에 계산을 사용하지 마세요.

where 절에서 인덱스 열이 계산이나 함수의 일부인 경우 DBMS 최적화 프로그램은 인덱스를 사용하지 않고 전체 테이블 쿼리 유형을 사용합니다. , EXISTS는 일반적으로 in에 사용되며 in은 인덱스를 사용하지 않기 때문에 동시에 존재합니다.

낮은 효율성:

 select * from user where salary*22>11000(salary是索引列)

로그인 후 복사

높은 효율성:

 select * from user where salary>11000/22(salary是索引列)

로그인 후 복사

3. 미리 컴파일된 쿼리 사용

프로그램은 일반적으로 동적 기반입니다. 사용자 입력 SQL을 실행할 때 매개변수화된 SQL을 사용해야 합니다. 이렇게 하면 SQL 주입 취약점 공격을 피할 수 있을 뿐만 아니라 가장 중요한 것은 데이터베이스가 이러한 매개변수화된 SQL을 사전 컴파일하여 DBMS가 이 SQL에 대한 쿼리 최적화를 수행한다는 것입니다. 그리고 사전 컴파일을 수행하면 나중에 이 SQL을 실행할 때 사전 컴파일된 결과가 바로 사용되므로 실행 속도가 크게 향상될 수 있습니다.

4. 여러 SQL 문을 하나의 SQL 문으로 압축해 보세요

SQL을 실행할 때마다 네트워크 연결을 설정하고, 권한 확인을 수행하고, SQL 문에 대한 쿼리를 최적화하고, 실행 결과를 보내는 과정입니다. 시간이 많이 걸리므로 너무 많은 SQL 문을 실행하지 않도록 해야 합니다. 하나의 SQL 문으로 압축할 수 있으면 여러 SQL 문을 사용하여 실행하지 마세요.

5. HAVING 절을 where 절로 바꿉니다.

HAVING 절은 모든 레코드를 검색한 후에만 결과 집합을 필터링하는 반면 where 절을 전달할 수 있는 경우 집계하기 전에 결과 집합을 필터링하기 때문에 사용하지 마세요. 레코드 수를 늘리면 이러한 오버헤드를 줄일 수 있습니다. HAVING의 조건은 일반적으로 집계 함수를 필터링하는 데 사용됩니다. 또한 조건은 where 절에 작성되어야 합니다.

6. 테이블 별칭 사용

SQL 문에서 여러 테이블을 연결할 때는 테이블 별칭을 사용하고 각 열 이름 앞에 별칭을 붙입니다. 이를 통해 구문 분석 시간을 줄이고 친구 열 이름의 모호함으로 인해 발생하는 문법 오류를 줄일 수 있습니다.

7. Union을 Union All로 교체

SQL 문에서 두 쿼리 결과 집합의 합집합이 필요한 경우 검색 결과에 중복 레코드가 없더라도 합집합을 사용하면 두 결과 집합도 병합을 시도합니다. 그런 다음 최종 결과를 출력하기 전에 Sorting을 수행하므로 검색 결과에서 중복된 기록이 없을 것이라고 판단할 수 있는 경우 Union All을 사용해야 효율성이 향상됩니다.

8. "임시 테이블"을 사용하여 중간 결과를 임시로 저장하는 것을 고려하세요.

SQL 문을 단순화하는 중요한 방법은 임시 테이블을 사용하여 중간 결과를 임시로 저장하는 것입니다. 후속 쿼리는 tempdb에 저장되어 프로그램에서 기본 테이블을 여러 번 스캔하는 것을 방지할 수 있으며 프로그램 실행 중 "업데이트 잠금"을 차단하는 "공유 잠금"을 크게 줄여 차단을 줄이고 동시성 성능을 향상시킵니다. .

그러나 시스템 테이블 리소스 소비를 줄이기 위해 임시 테이블을 자주 생성하고 삭제하는 것도 피해야 합니다.

9. 필요한 경우에만 트랜잭션 시작 변환을 사용하세요.

SQL Server의 SQL 문은 기본적으로 트랜잭션이며 문이 실행된 후에 기본적으로 커밋됩니다. 실제로 이것은 start tran이 각 문의 시작 부분에 암시되고 커밋이 끝에 암시되는 것처럼 최소화된 형태의 start tran입니다.

어떤 경우에는 start tran을 명시적으로 선언해야 합니다. 예를 들어 "삽입, 삭제 및 수정" 작업을 수행할 때 여러 테이블을 동시에 수정해야 합니다. 성공했거나 그 중 누구도 성공하지 못했습니다. Begin tran은 여러 SQL 문을 함께 실행하고 최종적으로 함께 커밋할 수 있는 역할을 할 수 있습니다. 장점은 데이터 일관성이 보장되지만 완벽한 것은 없다는 것입니다. Begin tran이 지불하는 대가는 제출 전에 SQL 문에 의해 잠긴 모든 리소스가 커밋될 때까지 해제될 수 없다는 것입니다.

Begin tran이 너무 많은 SQL 문을 트랩하면 데이터베이스 성능이 끔찍할 것임을 알 수 있습니다. 대규모 트랜잭션이 커밋되기 전에는 필연적으로 다른 문이 차단되어 많은 차단이 발생하게 됩니다.

Begin tran을 사용하는 원칙은 데이터 일관성 보장을 전제로 start tran에 의해 트랩되는 SQL 문이 적을수록 더 좋다는 것입니다! 어떤 경우에는 트리거를 사용하여 데이터를 동기화할 수 있으며 start tran이 반드시 사용되는 것은 아닙니다.