MySQL 데이터베이스의 일반적인 기술은 무엇입니까?

1. 서버 유형을 선택하는 방법은 무엇입니까?

MySQL 서버 구성 창의 각 매개변수의 의미는 다음과 같습니다.

이 옵션은 서버의 구성 유형을 지정하는 데 사용됩니다. 이 옵션 오른쪽에 있는 아래쪽 버튼을 클릭하면 3가지 옵션이 표시됩니다.

세 가지 옵션의 구체적인 의미는 다음과 같습니다.

이 옵션은 일반적인 개발용 개인 데스크톱 워크스테이션을 나타냅니다. 컴퓨터에서 여러 데스크톱 응용 프로그램이 실행되고 있다고 가정합니다. 최소한의 시스템 리소스를 사용하도록 MySQL 서버를 구성합니다.

Server Machine(서버): 이 옵션은 MySQL 서버가 FTP, 이메일, 웹 서버와 같은 다른 애플리케이션과 함께 실행될 수 있음을 나타냅니다. MySQL 서버는 적절한 비율의 시스템 리소스를 사용하도록 구성됩니다.

DedicatedMySQL Server Machine(MySQL 전용 서버): 이 옵션은 MySQL 서비스만 실행하는 서버를 나타냅니다. 다른 응용 프로그램이 실행되고 있지 않다고 가정합니다. MySQL 서버는 사용 가능한 모든 시스템 리소스를 사용하도록 구성되었습니다. 초보자라면 시스템 리소스를 적게 차지하는 [개발용 머신] 옵션을 선택하는 것이 좋습니다.

2. MySQL에서 특수 문자를 사용하는 방법은 무엇입니까?

작은따옴표('), 큰따옴표("), 백슬래시() 등의 기호입니다. 이러한 기호는 MySQL에서 직접 입력하여 사용할 수 없으며 그렇지 않으면 예상치 못한 결과가 발생합니다. MySQL에서는 이러한 특수 문자가 라는 문자를 이스케이프하려면 입력이 백슬래시 기호('')로 시작해야 하므로 작은따옴표와 큰따옴표를 사용할 때는 각각 (') 또는 (")를 입력해야 하고, 백슬래시를 입력할 때는 ( ), 기타 특수 문자로는 캐리지 리턴(), 줄 바꿈(), 탭(ab), 백스페이스() 등이 있습니다. 이러한 특수 문자를 데이터베이스에 삽입할 때는 이스케이프해야 합니다.

3. MySQL은 대소문자 구분 문자열 비교를 어떻게 수행합니까?

MySQL은 Windows 플랫폼에서 대소문자를 구분하지 않으므로 문자열 비교 기능도 대소문자를 구분하지 않습니다. 대소문자를 구분하여 비교하려면 문자열 앞에 BINARY 키워드를 사용하세요. 예를 들어, 기본적으로 'a'='A'의 반환 결과는 1입니다. BINARY 키워드를 사용하는 경우 BINARY'a'='A'의 결과는 0입니다. 대소문자 구분의 경우 'a' 및 'A' 동일하지 않습니다.

MySQL 문 최적화 기술

MySQL 데이터베이스 성능 최적화는 MySQL 데이터베이스 개발을 위한 유일한 방법입니다. MySQL 데이터베이스 성능 최적화는 MySQL 데이터베이스의 발전을 보여주는 증거이기도 합니다. :

1. where 절에 != 또는 <> 연산자를 사용하지 마십시오. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 전체 테이블 스캔을 수행합니다.

쿼리를 최적화하려면 전체 테이블 스캔을 최대한 피해야 합니다. 그런 다음 where 및 order by와 관련된 열에 대한 인덱스 구축의 우선 순위를 지정해야 합니다.

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 '�c%'

효율성을 높이기 위해 전체 텍스트 검색을 고려할 수 있습니다.

6. In과 not in도 주의해서 사용해야 합니다. 그렇지 않으면 다음과 같이 전체 테이블 스캔이 발생합니다.

select id from t where num in (1,2,3)

연속 값의 경우 가능한 경우 between을 사용하지 마세요. 사용:

select id from t where num between 1

7. where 절에 매개변수를 사용하면 전체 테이블 스캔이 발생합니다. SQL은 런타임 시에만 지역 변수를 분석하므로 옵티마이저는 런타임까지 액세스 계획 선택을 연기할 수 없습니다. 컴파일 시 선택해야 합니다. 액세스 계획이 컴파일 시간에 빌드되고 변수 값을 알 수 없는 경우 이 값을 인덱스 선택을 위한 입력으로 사용할 수 없습니다. 예를 들어, 다음 명령문은 전체 테이블 스캔을 수행합니다.

select id from t where num=@num

를 변경하여 쿼리가 인덱스를 사용하도록 강제할 수 있습니다.

select id from t with(index(index name )) 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'--이름이 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 createate>='2005-11-30′ 그리고 < ;'2005-12-1′

10. where 절의 "=" 왼쪽에서는 함수, 산술 연산 또는 기타 표현식 연산을 수행하지 마십시오. 그렇지 않으면 시스템이 인덱스를 올바르게 사용하지 못할 수 있습니다.

11. 인덱스 필드를 조건으로 사용할 때 인덱스가 복합 인덱스인 경우 시스템이 인덱스를 사용하는지 확인하기 위해 인덱스의 첫 번째 필드를 조건으로 사용해야 합니다. 그렇지 않으면 인덱스가 사용되지 않습니다. 그리고 필드 순서는 인덱스 순서와 최대한 일치해야 합니다.

12. 의미 없는 쿼리를 작성하지 마세요. 예를 들어 빈 테이블 구조를 생성해야 합니다.

select col1,col2 into #t from t where 1=0

이 유형의 코드는 결과 집합을 반환하지 않습니다. , 그러나 시스템 리소스는 다음과 같이 변경되어야 합니다:

create table #t(...)

13 다음 대신에 존재하는 것을 사용하는 것이 좋은 선택입니다:

where num에서 num 선택 in (select num from b)

다음 문으로 바꿉니다:

select num from a where presents (select 1 from b where num=a.num)

14 SQL 최적화 쿼리에 유효한 것은 아닙니다. 예, 인덱스 열에 중복된 데이터가 많은 경우 SQL 쿼리는 인덱스를 사용하지 않을 수 있습니다. 예를 들어 테이블에 섹스 필드가 있고 거의 절반이 남성과 절반은 여성인 경우 성별을 기반으로 인덱스를 구축하더라도 쿼리 효율성에는 아무런 영향을 미치지 않습니다.

15. 인덱스는 많을수록 좋습니다. 하지만 인덱스는 해당 선택의 효율성을 향상시킬 수 있지만 삽입이나 업데이트 중에 인덱스가 다시 작성될 수 있으므로 주의가 필요합니다. 인덱스를 구축하는 방법은 사례별로 고려됩니다. 한 테이블에 6개 이상의 인덱스를 두지 않는 것이 가장 좋습니다. 이 수를 초과하는 경우 자주 사용되지 않는 일부 열에 인덱스를 생성해야 하는지 여부를 고려해야 합니다.

16. 클러스터형 인덱스 데이터 열의 순서는 테이블 레코드의 물리적 저장 순서이기 때문에 가능한 한 업데이트를 피해야 합니다. 열 값이 변경되면 전체 테이블 레코드의 순서가 변경됩니다. 조정해야 하므로 시간이 많이 소요됩니다. 응용 프로그램 시스템이 클러스터형 인덱스 데이터 열을 자주 업데이트해야 하는 경우 인덱스를 클러스터형 인덱스로 구축해야 하는지 여부를 고려해야 합니다.

17. 숫자 필드를 사용해 보십시오. 필드에 숫자 정보만 포함되어 있으면 쿼리 및 연결 성능이 저하되고 저장 오버헤드가 증가합니다. 엔진은 쿼리 및 조인을 처리할 때 문자열의 각 문자를 하나씩 비교하므로 숫자 유형은 하나씩 비교하는 대신 한 번만 비교하면 됩니다.

18. char/nchar 대신 varchar/nvarchar를 사용하세요. 우선 가변 길이 필드는 저장 공간이 작아서 저장 공간을 절약할 수 있기 때문입니다. 두 번째로 쿼리의 경우 상대적으로 작은 필드에서 검색 효율성이 떨어집니다. 분명히 더 높습니다.

19. 어디에서나 select *를 사용하지 말고, "*"를 특정 필드 목록으로 바꾸고, 사용하지 않는 필드를 반환하지 마세요.

20. 임시 테이블 대신 테이블 변수를 사용해 보세요. 테이블 변수에 많은 양의 데이터가 포함되어 있는 경우 인덱스가 매우 제한적이라는 점에 유의하세요(기본 키 인덱스만 해당).

21. 시스템 테이블 리소스 소비를 줄이려면 임시 테이블을 자주 생성하고 삭제하지 마세요.

22. 임시 테이블은 사용할 수 없습니다. 예를 들어 큰 테이블이나 일반적으로 사용되는 테이블의 데이터 세트를 반복적으로 참조해야 하는 경우 임시 테이블을 적절하게 사용하면 특정 루틴을 더 효율적으로 사용할 수 있습니다. 그러나 일회성 이벤트의 경우 내보내기 테이블을 사용하는 것이 좋습니다.

23. 임시 테이블을 생성할 때 한 번에 삽입되는 데이터의 양이 많은 경우 테이블 생성 대신 select into를 사용하면 많은 로그 발생을 방지하고 데이터 양이 많은 경우 속도를 향상시킬 수 있습니다. 규모가 크지 않으므로 시스템 테이블의 자원을 용이하게 하기 위해 테이블을 먼저 생성한 후 삽입해야 합니다.

24. 임시 테이블을 사용하는 경우 저장 프로시저가 끝날 때 모든 임시 테이블을 명시적으로 삭제해야 합니다. 이렇게 하면 시스템 테이블이 장기간 잠기는 것을 방지할 수 있습니다.

25. 커서로 작동하는 데이터가 10,000행을 초과하는 경우에는 커서를 사용하지 않는 것이 좋습니다.

26. 대규모 트랜잭션 작업을 피하고 시스템 동시성을 개선하세요.

위 내용은 MySQL 데이터베이스의 일반적인 기술은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!