MySQL 데이터베이스 설계 요약

규칙 1: 일반적으로 MyISAM 스토리지 엔진을 선택할 수 있습니다. 트랜잭션 지원이 필요한 경우 InnoDB 스토리지 엔진을 사용해야 합니다.

참고: MyISAM 스토리지 엔진 B-트리 인덱스에는 큰 제한이 있습니다. 인덱스에 참여하는 모든 필드의 길이의 합은 1000바이트를 초과할 수 없습니다. 또한 MyISAM 데이터와 인덱스가 분리되어 있는 반면 InnoDB의 데이터 저장은 클러스터 인덱스를 기준으로 하며 기본 키가 기본 클러스터 인덱스이므로 MyISAM은 일반적으로 InnoDB보다 쿼리 성능이 높지만 InnoDB의 쿼리 성능은 기본 키를 기반으로 합니다. 키가 매우 높습니다.

규칙 2: 명명 규칙.

1. 데이터베이스 및 테이블 이름은 서비스되는 비즈니스 모듈 이름과 최대한 일치해야 합니다.

2. 일류 테이블 서비스 동일한 하위 모듈은 최대한 일관성을 유지해야 합니다. 하위 모듈 이름(또는 단어의 일부)을 접두사 또는 접미사로 사용하세요.

3. 테이블 이름은 다음에 해당하는 단어를 포함해야 합니다. 저장된 데이터

4. 필드 이름도 실제 데이터와 일치하도록 노력해야 합니다.

5. 공동 인덱스 이름은 모든 데이터를 포함해야 합니다. 인덱스 키 필드 이름 또는 약어, 인덱스 이름의 각 필드 이름 순서는 인덱스 키와 일치해야 합니다. 인덱스의 인덱스 순서는 일관적이며 객체가 해당 개체임을 나타내기 위해 idx와 유사한 접두사 또는 접미사를 포함하려고 합니다. 유형은 인덱스입니다.

6. 제약조건과 같은 기타 개체에도 해당 관계를 나타내기 위해 해당 개체가 속한 테이블이나 다른 개체의 이름을 최대한 포함해야 합니다.

규칙 3: 데이터베이스 필드 유형 정의

1. CPU를 소비하는 계산 및 정렬이 자주 필요한 필드의 경우 다음을 사용하는 등 더 빠른 필드를 선택해야 합니다. TIMESTAMP(4자 섹션, 최소값 1970-01-01 00:00:00) Datetime(8바이트, 최소값 1001-01-01 00:00:00) 대신 부동 소수점 및 문자 유형 교체 정수 포함

2. 가변 길이 필드에는 varchar을 사용하고, char

3. 은 사용하지 마세요. 바이너리 멀티미디어 데이터, 파이프라인 데이터(예: 로그), 매우 큽니다 데이터베이스 필드에 텍스트 데이터를 배치하지 마십시오.

규칙 4: 비즈니스 로직 실행 프로세스에서 읽어야 하는 테이블에는 초기값. 프로그램 오류를 유발하는 음수 또는 무한 값의 비즈니스 판독 방지

규칙 5: 패러다임 이론, 적당한 중복성을 고수할 필요는 없으므로 쿼리가 조인을 최소화할 수 있습니다

규칙 6: 액세스 빈도가 낮은 대규모 필드를 데이터 테이블로 분할합니다. 일부 큰 필드는 많은 공간을 차지하고 다른 필드에 비해 훨씬 덜 자주 액세스됩니다. 이 경우 필드를 분할하면 빈번한 쿼리에서 큰 필드를 읽을 필요가 없으므로 IO 리소스가 낭비됩니다.

규칙 7: 큰 테이블의 경우 수평 분할을 고려할 수 있습니다. 큰 테이블은 쿼리 효율성에 영향을 미칩니다. 비즈니스 특성에 따라 분할 방법이 많이 있습니다. 예를 들어 시간에 따라 증가하는 데이터를 시간에 따라 분할할 수 있습니다. id로 나눈 데이터는 데이터베이스의 id% 수에 따라 분할될 수 있습니다.

규칙 8: 비즈니스에 필요한 해당 인덱스는 실제 설계에 따라 구성된 SQL 문의 where 조건에 따라 결정됩니다. 공동 인덱스(또는 기본 키)에는 둘 이상의 필드가 포함되어 있습니다. 특히 해당 필드는 조건문에 전혀 표시되지 않습니다.

규칙 9: 레코드의 하나 이상의 필드를 고유하게 결정하려면 기본 키 또는 고유 인덱스를 설정해야 합니다. 레코드를 고유하게 결정할 수 없는 경우 공통 인덱스가 구축됩니다. 쿼리 효율성 향상

규칙 10: 비즈니스에서 사용하는 일부 테이블에는 레코드가 매우 적거나 레코드가 하나만 있는 경우 제약 조건 요구 사항을 충족하려면 인덱스 또는 기본 키를 설정해야 합니다. .

규칙 11: 값이 반복될 수 없고 쿼리 조건으로 자주 사용되는 필드의 경우 고유 인덱스를 작성해야 하며(기본 키는 기본적으로 고유 인덱스로 설정됨) 쿼리 조건에서 이 필드의 조건은 첫 번째 위치에 배치되어야 합니다. 이 필드와 관련된 공동 인덱스를 만들 필요가 없습니다.

규칙 12: 값이 고유하지 않은 자주 쿼리되는 필드의 경우 쿼리 문 및 프로세스의 첫 번째 위치에 필드 조건을 설정하는 것도 고려해야 합니다. 조인트 인덱스도 마찬가지다.

규칙 13: 기업이 고유하지 않은 인덱스를 통해 데이터에 액세스하는 경우 인덱스 값을 통해 반환되는 레코드 밀도를 고려해야 합니다. 원칙적으로 가능한 최대 밀도는 더 높을 수 없습니다. 0.2보다 촘촘한 경우 차수가 너무 크면 인덱스 생성에 적합하지 않습니다.

이 인덱스를 통해 검색된 데이터의 양이 테이블 전체 데이터의 20% 이상을 차지하는 경우 인덱스 스캐닝으로 인해 랜덤 I이 발생하므로 인덱스 구축 비용도 함께 고려해야 합니다. /O, 결과적으로 전체 테이블 순차 스캔의 순차 I/O보다 효율성이 훨씬 낮습니다. 데이터베이스 시스템은 쿼리를 최적화할 때 이 인덱스를 사용하지 않을 수 있습니다.

규칙 14: 공동 인덱스(또는 공동 기본 키)가 필요한 데이터베이스는 인덱스 순서에 주의해야 합니다. SQL 문의 일치 조건도 인덱스 순서와 일치해야 합니다.

참고: 잘못된 색인 생성은 심각한 결과를 초래할 수도 있습니다.

규칙 15: 테이블의 여러 필드는 쿼리 조건으로 사용되며, 다른 인덱스를 포함하지 않으며, 필드의 결합 값이 반복되지 않습니다. 인덱스가 (a1, a2,...an)인 경우 쿼리 조건 (a1 op val1,a2 op val2,...am op valm)m<=n은 쿼리 조건의 필드 위치와 일치한다고 가정합니다. 인덱스의 필드입니다.

규칙 16: 결합 색인 설정 원칙(다음은 데이터베이스 테이블의 a, b, c 필드에 결합 색인(a, b, c)이 설정되어 있다고 가정합니다.)

1. 공동 인덱스의 필드는 필터링된 데이터의 순서를 가장 큰 것부터 가장 작은 것까지 만족시키도록 노력해야 합니다. 즉, 가장 큰 차이가 있는 필드가 첫 번째 필드가 되어야 합니다

2. 인덱스 생성은 SQL 문의 조건 순서와 최대한 일치해야 SQL 문이 전체 인덱스를 최대한 기준으로 작성되어야 하며, 사용을 피하도록 하세요. 인덱스의 일부(특히 첫 번째 조건이 인덱스의 첫 번째 필드와 일치하지 않는 경우)를 쿼리 조건으로

3. Where a=1,where a>=12 and a<15,where a=1 and b<5 ,where a=1 and b=7 and c>=40为条件可以用到此联合索引；而这些语句where b=10,where c=221,where b>=12 and c=2则无法用到这个联合索引。

4. 쿼리해야 하는 데이터베이스 필드가 모두 인덱스에 반영되면 테이블 전체를 스캔하지 않고 데이터베이스가 직접 인덱스를 쿼리하여 쿼리 정보를 얻을 수 있는(이른바 키 전용) 쿼리 효율성이 크게 향상됩니다.
   다른 테이블 필드와 연관하여 a, ab, abc를 쿼리할 때 인덱스를 사용할 수 있습니다.

5. b, c, bc, 대신 a, ab, abc가 순서대로 있을 때 ac. 정렬 기준 또는 그룹 실행 시 인덱스를 사용할 수 있습니다

6. 다음과 같은 상황에서는 공동 인덱스를 사용하는 것보다 테이블 검색 및 정렬이 더 효과적일 수 있습니다
   a. 인덱스에 따라 정리됨
   b. 쿼리된 데이터 스테이션에 있는 모든 데이터의 상당 부분.

규칙 17: 중요한 비즈니스가 데이터 테이블에 액세스할 때. 다만, 인덱스를 통해 데이터에 접근할 수 없는 경우에는 순차적으로 접근하는 레코드의 개수를 제한해야 하며, 원칙적으로 10개를 넘지 않도록 해야 한다.

규칙 18: 합리적으로 구성 쿼리문

1. 테스트에 따르면 Insert 문에서는 한 번에 1,000개의 항목을 한 번에 삽입하는 것이 가장 효율적입니다. 분할. 동일한 삽입이 여러 번 수행되는 경우 병합하고 일괄 처리해야 합니다. 쿼리 문의 길이는 mysqld 매개 변수 max_allowed_packet

2. 쿼리 조건에서 다양한 논리 연산자의 성능 순서가 and, or, in이므로 시도해야 합니다. 쿼리 조건에서 사용하지 않으려면

3. 에서 큰 세트를 사용할 때는 항상 작은 결과 세트를 사용하여 큰 레코드 세트를 구동하세요. 왜냐하면 mysql에는 하나만 있기 때문입니다. 조인 방법인 중첩 조인은 mysql의 조인이 중첩 루프를 통해 이루어짐을 의미합니다. 큰 레코드 세트를 구동하는 작은 결과 세트의 원리를 사용하여 중첩된 루프 루프 수를 줄여 총 IO 양과 CPU 작업 수를 줄입니다

4. 내부를 최적화해 보세요. 중첩 조인 루프.

5. 필수 열만 선택하고 선택은 사용하지 마세요. *

6. 가장 효과적인 필터 필드만 사용하세요. 필터 조건이 거의 없습니다. where 절 최선을 다해

7. 복잡한 조인과 하위 쿼리는 피하세요

   Mysql은 동시성이 너무 높으면 전반적으로 성능이 급격히 저하되는 것은 주로 Mysql 내부 리소스의 경합 잠금 제어와 관련이 있으며, InnoDB는 행 잠금을 사용합니다.

규칙 19: 응용 시스템 최적화

1. 변화가 적은 부분에 대해 캐시를 합리적으로 사용하십시오. 데이터는 애플리케이션 계층 캐시를 통해 메모리에 캐시되므로 성능이 몇 배나 향상됩니다.

2. 같은 쿼리를 반복적으로 병합하여 IO 수를 줄입니다.

c. 최소 거래 관련성 원칙

위 내용은 MySQL 데이터베이스 설계 요약의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!