1. 쿼리를 최적화하려면 전체 테이블 스캔을 피하십시오. 먼저 where 및 order by와 관련된 열에 인덱스를 생성하는 것을 고려하십시오.
2. where 절에 != 또는 a8093152e673feb7aba1828c43532094 연산자를 사용하지 마세요. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 전체 테이블 스캔을 수행합니다.
3. where 절의 필드에 대한 null 값 판단을 피하십시오. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 다음과 같이 전체 테이블 스캔을 수행합니다.
select id from t where num is null
num에 기본값 0을 설정할 수 있습니다. 테이블의 num 열에 null 값이 없는지 확인한 후 다음과 같이 쿼리하세요.
select id from t where num=0
4 조건을 연결하기 위해 where 절에 또는 사용을 피하세요. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 다음을 수행합니다. 전체 테이블 검색(예:
select id from t where num=10 or num=20
select id from t where num=10 union all select id from t where num=20
5)과 같이 쿼리할 수 있습니다. 다음 쿼리도 전체 테이블 검색을 수행합니다.
select id from t where name like '%abc%'
효율성을 높이려면 전체 텍스트 검색을 고려할 수 있습니다. .
6.in 및 not in도 주의해서 사용해야 합니다. 그렇지 않으면 다음과 같이 전체 테이블 스캔이 발생합니다.
select id from t where num in(1,2,3)
연속 값의 경우 between을 사용할 수 있으면 in을 사용하지 마세요:
select id from t where num between 1 and 3
7. where sub에 있는 경우 문장에 매개변수를 사용하면 전체 테이블 스캔이 발생합니다. SQL은 런타임 시에만 지역 변수를 분석하므로 옵티마이저는 런타임까지 액세스 계획 선택을 연기할 수 없습니다. 컴파일 시 선택해야 합니다. 그러나 액세스 계획이 컴파일 시간에 빌드되면 변수 값을 여전히 알 수 없으며 인덱스 선택을 위한 입력으로 사용할 수 없습니다. 예를 들어, 다음 명령문은 전체 테이블 스캔을 수행합니다.
select id from t where num=@num
쿼리가 인덱스를 사용하도록 이를 변경할 수 있습니다:
select id from t with(index(索引名)) where num=@num
8 표현식 작업은 피해야 합니다. where 절의 필드에 대해 이렇게 하면 엔진이 인덱스 사용을 포기하고 전체 테이블 스캔을 수행하게 됩니다. 예:
select id from t where num/2=100
는
select id from t where num=100*2
9로 변경해야 합니다. where 절의 필드에 기능적 작업을 수행하면 엔진이 인덱스 사용을 포기하고 전체 테이블 스캔을 수행하게 됩니다. 예:
select id from t where substring(name,1,3)='abc'--name以abc开头的id select id from t where datediff(day,createdate,'2005-11-30')=0--'2005-11-30'生成的id
는
select id from t where name like 'abc%' select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10으로 변경되어야 합니다. where 절의 "=" 왼쪽에서 함수, 산술 연산 또는 기타 표현식 연산을 수행하지 마십시오. 그렇지 않으면 시스템이 수행하지 못할 수 있습니다. 인덱스를 올바르게 사용하십시오.
11. 인덱스 필드를 조건으로 사용할 때 인덱스가 복합 인덱스인 경우 시스템이 인덱스를 사용하는지 확인하기 위해 인덱스의 첫 번째 필드를 조건으로 사용해야 합니다. 그렇지 않으면 인덱스가 사용되지 않습니다. 그리고 필드 순서는 인덱스 순서와 최대한 일치해야 합니다.
12. 의미 없는 쿼리를 작성하지 마세요. 예를 들어 빈 테이블 구조를 생성해야 하는 경우:
select col1,col2 into #t from t where 1=0
이 유형의 코드는 결과 집합을 반환하지 않지만 시스템 리소스를 소비하게 됩니다.
create table #t(...)
13. in 대신 기존을 사용하는 것이 좋은 선택인 경우가 많습니다.
select num from a where num in(select num from b)
다음 명령문으로 바꾸세요.
select num from a where exists(select 1 from b where num=a.num)
14 모든 인덱스가 쿼리에 효과적인 것은 아닙니다. SQL은 최적화합니다. 예, 인덱스 열에 중복된 데이터가 많은 경우 SQL 쿼리는 인덱스를 사용하지 않을 수 있습니다. 예를 들어 테이블에 섹스 필드가 있고 거의 절반이 있습니다. 남성과 절반은 여성인 경우 성별을 기반으로 인덱스를 구축하더라도 쿼리 효율성에는 아무런 영향을 미치지 않습니다.
15. 인덱스는 많을수록 좋습니다. 하지만 인덱스는 해당 선택의 효율성을 향상시킬 수 있지만 삽입이나 업데이트 중에 인덱스가 다시 작성될 수 있으므로 주의가 필요합니다. 인덱스를 구축하는 방법은 사례별로 고려됩니다. 하나의 테이블에 6개 이상의 인덱스를 두지 않는 것이 가장 좋으며, 인덱스가 너무 많으면 일반적으로 사용되지 않는 일부 컬럼에 인덱스를 구축할 필요가 있는지 고려해야 합니다.
16. 클러스터형 인덱스 데이터 열의 순서는 테이블 레코드의 물리적 저장 순서이므로 가능한 한 업데이트하지 않는 것이 좋습니다. 전체 테이블 레코드에는 많은 시간이 소요됩니다. 응용 프로그램 시스템이 클러스터형 인덱스 데이터 열을 자주 업데이트해야 하는 경우 인덱스를 클러스터형 인덱스로 구축해야 하는지 여부를 고려해야 합니다.
17. 숫자 필드를 사용해 보십시오. 필드에 숫자 정보만 포함되어 있으면 쿼리 및 연결 성능이 저하되고 저장 오버헤드가 증가합니다. 엔진은 쿼리 및 연결 처리 시 문자열의 각 문자를 하나씩 비교하는데, 숫자 유형의 경우 한 번의 비교만으로 충분하기 때문입니다.
18. char/nchar 대신 varchar/nvarchar를 최대한 사용하세요. 첫째, 가변 길이 필드의 저장 공간이 작아서 저장 공간을 절약할 수 있기 때문입니다. 둘째, 쿼리의 경우 상대적으로 작은 필드에서 검색 효율성이 향상됩니다. 분명히 더 높습니다.
19. 어디에서나 select *를 사용하지 말고, "*"를 특정 필드 목록으로 바꾸고, 사용하지 않는 필드를 반환하지 마세요.
20. 임시 테이블 대신 테이블 변수를 사용해 보세요. 테이블 변수에 많은 양의 데이터가 포함되어 있는 경우 인덱스가 매우 제한적이라는 점에 유의하세요(기본 키 인덱스만 해당).
21. 시스템 테이블 리소스 소비를 줄이려면 임시 테이블을 자주 생성하고 삭제하지 마세요.
위 내용은 일반적으로 사용되는 mysql 최적화 sql 문 쿼리 방법 요약의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!