사양 요약

인덱스 스펙

默认添加的索引都是BTree索引。Innodb只支持BTree索引。

设计索引原则

- 最适合索引的列是WHERE子句中的列，而不是SELECT中的列。
- 如果索引的字段很长，使用前缀索引
- 删除不常用索引
- 建议单表不超过5个

단일 테이블 인덱스가 5 개 이상 [인덱스 쿼리 성능을 향상시킬 수 있지만, 업데이트 된 플러그인의 효율성을 줄일 수]되지 않습니다
각 디비 테이블은 기본 키를 가져야 마스터 키 [추천] ID 값을 증분
권장 인덱스 열
- 열에서 문을 SELECT, UPDATE의 WHERE 절에 나타나지 삭제
- 그것은에서 ORDER BY 필드, GROUP BY, DISTINCT 포함
- 공동 인덱스 필드를 설정하기 위해 열 (1)과 (2)는 인덱스를 설립 필드, 일반적으로 더 나은을 충족하지 않는 1, 2
- 멀티 테이블 협회 열 가입
중복 인덱스와 인덱스 반복을 만들지 마십시오
- 예 중복 지수 : 기본 키 (ID), 인덱스 (ID), 고유 인덱스 (ID)
- 예 중복 지수 : 지표 (A, B, C), 인덱스 (a, b), 인덱스 (a)
커버링 인덱스

계속 될
외래 키 제약 오프

규범의 개발

당신은 SELECT <필드 목록> 쿼리를 사용해야합니다 * SELECT의 사용을 금지
대신 작업 하위 쿼리를 조인
바람직 연관된 테이블 조인하게는 5를 초과하여
또는 동일한 열에 대응의 판정 또는 대신에 사용될 때
랜드에 의해 질서의 사용을 금지 () 임의의 순서

[프로그램의 임의의 값을 획득 추천 데이터는 데이터베이스로부터 획득되는 방법. ]
WHERE 절에 열을 변환하는 기능을 금지 계산

[컬럼이 변환 또는 계산의 함수 인 경우에 사용할 수없는 인덱스 리드]
사용 UNION이 ALL 때 분명히 대신 UNION의 반복되지 않는 값을가 없을 것
- 모든 데이터는 다시 UNION이되는 다음 임시 테이블에 두 개의 결과 집합을 운영 할 것
- UNION ALL은 더 이상 결과는 시도로 설정
여러 개의 작은 SQL에 큰 복잡한 SQL을 분할
- 대형 SQL 로직은 SQL의 더 복잡한, CPU를 많이 사용하는 계산입니다
- MySQL을하는 SQL에만 CPU를 사용하여 계산 될 수있다
- 는 SQL 해상도의 처리 효율을 향상하기 위해 병렬로 수행 될 수 후

인덱스 설계 사양

1. 각 테이블에서 인덱스의 수를 제한, 하나의 테이블 인덱스 5 개 이상 사용하지 않는 것이 좋습니다

인덱스는하지 낫다! 효율성을 향상시킬 수 인덱스는 효율성을 줄일 수 있습니다.

인덱스는 쿼리의 효율성을 높일 수 있습니다뿐만 아니라 삽입 및 업데이트의 효율성을 줄일 수, 심지어 어떤 경우에는 쿼리의 효율성을 줄일 수 있습니다.

쿼리 기반 통합 메시징을 최적화하는 방법을 선택할 때 MySQL의 최적화 때문에 각 인덱스를 생성, 평가하는 데 사용할 수있는 최적의 실행 계획을 조회 할 수 있습니다 동시에 여러 인덱스가있는 경우, MySQL은 또한 쿼리 성능이 저하됩니다, 시간 최적화 프로그램이 실행 계획을 생성 증가 할 것이다.

2. 각 이노 디비 테이블에는 기본 키가 있어야합니다

논리적 순서와 순서 인덱스 저장된 데이터는 동일합니다 : 이노 디비 인덱스 구성 테이블입니다. 각 테이블에 여러 인덱스가있을 수 있습니다, 테이블의 저장 순서가 하나있다.

이노 디비는 기본 키 인덱스 구성 테이블의 순서에

기본 키 (공동 인덱스에 해당) 다중 열 기본 키에 적용되지 같이 자주 업데이트되는 열을 사용하지 마십시오
UUID, MD5, HASH, 기본 키와 같은 문자열 열을 사용하지 마십시오 (데이터 성장의 순서를 보장하지 않음)
[기본 키 값 증분 ID 추천]

일반적인 권장 사항 인덱스 열

열에서 문을 SELECT, UPDATE의 WHERE 절에 나타나지 삭제
그것은에서 ORDER BY 필드, GROUP BY, DISTINCT 포함
공동 인덱스 필드를 설정하기 위해 열 (1)과 (2)는 인덱스를 설립 필드, 일반적으로 더 나은을 충족하지 않는 1, 2
멀티 테이블 협회 열 가입

중복 및 중복 인덱스 인덱스 생성 피 (질의 최적화의 시간이 증가하여 실행 계획을 생성한다)

예 중복 지수 : 기본 키 (ID), 인덱스 (ID), 고유 인덱스 (ID)
예 중복 지수 : 지표 (A, B, C), 인덱스 (a, b), 인덱스 (a)

빈번한 질의 우선 순위가 포함 인덱스를 사용하는

피복 률 : 모든 쿼리 필드 (여기서, 선택에 의해, 필드별로 그룹화 포함 ordery) 인덱스 포함

인덱스 혜택을 커버 :

색인 보조 쿼리 테이블을 피하기 이노 디비 : 보조 인덱스가 쿼리 데이터 인 경우 이노 디비는 디비를 들어, 저장하는 순차적 인 인덱스 집계, 리프 노드에 저장되어있는 두 개의 인덱스는 기본 키 정보 라인이며, 다음, 해당 키를 찾은 후, 우리는 기본 키에 의해 두 번째 쿼리를 수행하는 데 필요한 실제 데이터를 얻을 수 있습니다. 커버 인덱스에는 인덱스의 두 키 값을 검색 효율을 향상시키고, 상기 기본 쿼리에 대한 2 차 키를 회피 IO 동작을 줄일 모든 데이터를 획득 할 수있다.
랜덤 IO 순서 IO로 질의 효율을 촉진 할 수 커버링 인덱스 집중 IO위한 레인지 룩업을위한 키 값의 순서로 저장되어 있기 때문에, 각 라인의 IO 비교 랜덤 액세스 데이터 그래서, 디스크 덜 될 IO는 IO를 찾을 수있는 인덱스의 순서로 디스크를 읽을 수있는 랜덤 액세스 동안 인덱스를 포함하는 사용합니다.

6. SET 지수 사양

외래 키 제약 조건을 사용하지 마십시오

우리는 외래 키 제약 (외래 키)의 사용을 권장하지 않습니다 있지만 테이블과 테이블 사이의 관련 채권에 반드시 인덱스
데이터 무결성을 보장하기 위해 사용 외래 키 참조,의 사업 목적을 달성하는 것이 좋습니다
외래 키는 부모에 영향을 미칠 것와 자식 테이블은 작업이의 성능이 저하 쓰기

데이터베이스 SQL 개발 사양

당신은 SELECT <필드 목록> 쿼리를 사용해야합니다 * SELECT의 사용을 금지

이유 :

네트워크 대역폭에 더 많은 CPU 및 IO 자원을 소비
당신은 커버 인덱스를 사용할 수 없습니다
당신은 변경 테이블 구조의 영향을 줄일 수 있습니다

하위 쿼리를 사용하지 마십시오, 당신은 작업을 가입하는 쿼리 최적화를 처리 할 수 있습니다

일반적으로 쿼리의 하위 절 및 하위 쿼리에서 간단한 SQL이 (노동 조합에 의해 그룹, 제한 조항에 의해 순서를 포함하지 않는다)이다, 쿼리 최적화 관련 문의를 처리하기 위해 변환 할 수 있습니다.

성능 저하의 하위 쿼리 원인 :

임시 테이블 또는 디스크 메모리 임시 테이블 인덱스를 존재하지 여부를 하위 쿼리 결과 세트는, 일반적으로 서브 쿼리의 결과 집합은 임시 테이블에 저장되어있는 인덱스를 사용하지 수, 쿼리 성능이 어느 정도 영향을받습니다. 특히 반환 결과 집합 상대적으로 큰 서브 쿼리, 쿼리 성능에 큰 미치는 영향에 대한.

임시 테이블을 많이 생산할 예정 하위 쿼리가 인덱스가 없기 때문에, 그것은 느린 쿼리 많은 수의 결과, 과도한 CPU 및 IO 리소스를 소모합니다.

너무 많은 연관 테이블을 조인을 사용하지 마십시오

MySQL 용 연관 캐시의 존재는, 캐시 크기 파라미터 join_buffer_size 의해 설정 될 수있다.

동일한 협회 (가입)을 테이블의 MySQL, SQL 더욱에서는, 메모리의 더 관련된 표의 경우 큰 양을 멀티 관련 캐시, SQL을 할당한다.

불합리한 join_buffer_size 세트의 경우, 서버 메모리 오버 플로우를 야기하기 쉽다 동안 프로그램이 멀티 테이블의 운영과 관련된 사용을 많이하는 경우, 서버 데이터베이스 성능의 안정성에 영향을 미칠 것입니다.

협회 작업에 동시에 작업이 쿼리의 효율성에 영향을 미치는 임시 테이블을 생성 할 것이다, MySQL은, 61 관련 테이블에 최대 수 5 인 이상을 권장합니다.

또는 동일한 열에 대응의 판정 또는 대신에 사용될 때

작업을보다 효율적으로 인덱스의 사용 또는 대부분의 경우에 500 이하의 값에 거의 인덱스를 사용하지 않습니다.

랜드에 의해 질서의 사용을 금지 () 임의의 순서

모든 자격 데이터를 나열한다 (랜드에 의해 순서)를 메모리에로드하고 정렬 메모리의 모든 데이터에 대한 랜덤하게 생성 된 값에 따라, 각 열은 상태의 경우, 무작위로 생성 된 값을 가질 수있다 데이터 집합이 매우 큰, 그것은 CPU 및 IO 및 메모리 리소스를 많이 소비합니다.

프로그램의 임의의 값을 얻는 추천, 데이터는 데이터베이스에서 어떻게 획득.

WHERE 절에 열을 변환하는 기능을 금지 계산

열 전환 또는 계산 함수가 될 때 인덱스를 사용할 수없는 발생할

권장하지 않음 :

where date(create_time)='20190101'

권장 사항 :

where create_time >= '20190101' and create_time < '20190102'

사용 UNION이 ALL 때 분명히 대신 UNION의 반복되지 않는 값을가 없을 것

모든 데이터는 다시 UNION이되는 다음 임시 테이블에 두 개의 결과 집합을 운영 할 것
UNION ALL은 더 이상 결과는 시도로 설정

여러 개의 작은 SQL에 큰 복잡한 SQL을 분할

대형 SQL 로직은 SQL의 더 복잡한, CPU를 많이 사용하는 계산입니다
MySQL을하는 SQL에만 CPU를 사용하여 계산 될 수있다
는 SQL 해상도의 처리 효율을 향상하기 위해 병렬로 수행 될 수 후

참고 자료

아주 완전한 사양의 MySQL

https://baijiahao.baidu.com/s?id=1622786252178335118&wfr=spider&for=pc

MySQL의 인덱스 && 개발 사양