데이터베이스 캐치-30

데이터베이스용 Catch-30

1. 기본 사양

(1) InnoDB 스토리지 엔진을 사용해야 합니다.

해석: 트랜잭션 지원, 행 수준 잠금, 더 나은 동시성 성능, CPU 및 메모리 캐시 페이지 최적화로 리소스 활용도가 높아집니다

(2) UTF8 문자 집합을 사용해야 합니다

해석: 유니코드, 트랜스코딩 필요 없음, 잘못된 코드 위험 없음, 공간 절약

(3) 데이터 테이블과 데이터 필드는 반드시 중국어 주석 추가

해석: N년 안에 r1, r2, r3 필드가 무엇인지 알 수 있는 사람

(4) 저장 프로시저, 뷰, 트리거 및 이벤트를 사용하는 것은 금지되어 있습니다.

해석: 높은 동시성 빅 데이터 인터넷 비즈니스 및 아키텍처 디자인 아이디어는"데이터베이스 CPU를 해방하고 계산을 서비스 계층으로 전송"입니다. 서비스 계층에 비즈니스 로직을 배치하면 확장성이 향상되고"머신이 늘어나면 성능도 향상됩니다"를 쉽게 달성할 수 있습니다. 데이터베이스는 저장 및 인덱싱 기능이 뛰어나므로 CPU 계산을 위로 올려야 합니다

(5) 대용량 파일이나 사진을 저장하는 것은 금지되어 있습니다

해석: 왜 데이터베이스가 잘 하지 못하는 일을 하게 놔두나요? 대용량 파일과 사진은 파일 시스템에 저장됩니다. 데이터베이스에 URI를 저장하는 것이 얼마나 좋은가요? 2. 명명 규칙

(6) 데이터베이스에 연결하려면 IP가 아닌 인트라넷 도메인 이름만 사용할 수 있습니다. (7) 온라인 환경 및 개발 환경 및 테스트 환경 데이터베이스 인트라넷 도메인 이름은 명명 규칙을 따릅니다

● 업체명: xxx

● 온라인 환경: dj.xxx.db

● 개발 환경: dj.xxx.rdb

● 테스트 환경 : dj.xxx .tdb

● 슬레이브 데이터베이스 이름 뒤에 -s 표시를 추가하고, 대기 데이터베이스 이름 뒤에 -ss 표시를 추가하세요

● 온라인 슬레이브 데이터베이스 : dj.xxx-s .db

● 온라인 대기 데이터베이스: dj.xxx -sss.db

(8) 라이브러리 이름, 테이블 이름, 필드 이름: 소문자, 밑줄 스타일, 32자 이내, 이름은 명확하게 이해되어야 함, 혼합 금지 병음, 영문 허용

(9) 테이블 이름 t_xxx, 고유 아님 인덱스 이름 idx_xxx, 고유 인덱스 이름 uniq_xxx

3. 테이블 디자인 사양

(10) 단일 인스턴스 테이블 수는 500개 미만이어야 합니다. (11) 단일 테이블의 열 수는 30개 미만이어야 합니다.

(12) 테이블에는 기본 키가 있어야 합니다(예: 자동 증가 기본 키)

해석:

* a) 기본 키 증분, 데이터 행 쓰기는 삽입 성능을 향상시키고 '페이지' 분할을 방지하며 테이블 조각화를 줄이고 공간 및 메모리 사용량을 향상시킬 수 있습니다

* b) 기본 키 선택 더 짧은 데이터 유형의 경우 Innodb 엔진 일반 인덱스는 기본 키 값을 저장합니다. . 더 짧은 데이터 유형은 인덱스의 디스크 공간을 효과적으로 줄이고 인덱스의 캐시 효율성을 향상시킬 수 있습니다

* c) 행 모드에서 기본 키가 없는 테이블 삭제 마스터-슬레이브 아키텍처로 인해 대기 데이터베이스가 차단됩니다

(13) 외래 키 무결성 제약이 있는 경우 애플리케이션 제어가 필요합니다.

해석: 외래 키는 테이블 간 결합을 유발합니다. 삭제 작업에는 관련 테이블이 포함되어 SQL 성능에 큰 영향을 미치고 교착 상태를 유발할 수도 있습니다. 동시성이 높으면 데이터베이스 성능이 쉽게 저하될 수 있습니다.

필드 설계 사양

( 14) 필드는 NOT NULL로 정의되어야 하며 기본값은 제공되어야 합니다해석:

* a) Null 열은 인덱스/인덱스 통계/값 비교를 더 복잡하고 MySQL에 최적화하기 어렵게 만듭니다

* b) null 이 유형의 MySQL은 내부적으로 특별한 처리가 필요하므로 동일한 조건에서 데이터베이스 처리 레코드의 복잡성이 증가합니다. 테이블에 빈 필드가 많으면 데이터베이스 처리 성능이 많이 저하됩니다

* c) Null 값은 더 많은 것을 필요로 합니다. Null을 저장하려면 테이블이나 인덱스의 각 행에 Null 열인지 식별할 수 있는 추가 공간이 필요합니다

* d) Null을 처리할 때는 `is null` 또는 `is not null`만 사용할 수 있으며, 그러나 not 연산 기호 `=, in, <, <>, !=, not in`을 사용하십시오. 예: name!='shenjian'인 경우 이름이 null 값인 레코드가 있는 경우 쿼리 결과에는 이름이 null 값인 레코드가 포함되지 않습니다

(15) TEXT 및 BLOB 유형을 사용할 수 없습니다

해석: 디스크와 메모리 공간이 더 많이 낭비되고 불필요한 대규모 필드 쿼리로 인해 핫 데이터가 제거되어 메모리 적중률이 급격히 감소하여 데이터베이스 성능에 영향을 미칩니다

(16) 통화를 저장하기 위해 소수를 사용하는 것은 금지되어 있습니다

해석: 정수를 사용, 소수는 쉽다 결과적으로 돈이 맞지 않는다

(17) 휴대폰 번호를 저장하려면 varchar(20)을 사용해야 합니다

해석:

* a) 지역번호의 경우 또는 국가번호 `+-()`

* b) 휴대폰 번호가 나타날 수 있습니다. 수학 연산을 할 수 있나요?

* c) varchar는 퍼지 쿼리를 지원할 수 있습니다. 예: `like "138%"`

(18) ENUM 사용은 금지되어 있으며 대신 TINYINT를 사용할 수 있습니다.

해석:

* a) 새 ENUM 추가 DDL 작업을 수행할 값

* b) ENUM의 실제 내부 저장 공간이 정수라고 생각하시나요?

5. 인덱스 디자인 사양

(19) 단일 테이블 인덱스는 5개 이내로 제어하는 ​​것이 좋습니다

(20) 단일 인덱스 필드 수는 5개를 초과할 수 없습니다

해석: 필드가 5개를 초과하는 경우 , 실제로 더 이상 가능하지 않습니다. 효과적으로 데이터 필터링

(21) 자주 업데이트되고 차별화가 낮은 속성에 대한 인덱스를 생성하는 것은 금지됩니다. 해석:

* a) 업데이트는 B+ 트리를 변경하고 인덱싱은 자주 업데이트됩니다. 필드는 비용을 크게 증가시킵니다. 데이터베이스 성능이 저하됩니다.

* b) "성별"과 같이 구분이 거의 없는 속성에 대해 인덱스를 생성하는 것은 데이터를 효과적으로 필터링할 수 없습니다.

(22) 결합 인덱스를 구축하려면 반드시 구별도가 높은 필드를 앞에 배치해야 합니다

해석: 데이터를 보다 효과적으로 필터링할 수 있습니다

6. SQL 사용 사양

(23) SELECT 사용을 금지합니다. *, 꼭 필요한 필드만 얻고, 설명 열 속성은 표시해야 합니다

해석:

* a) 불필요한 열을 읽으면 CPU, IO, NET 소비가 증가합니다

* b) Covering 인덱스를 효과적으로 사용할 수 없습니다

* c) 필드를 추가하거나 삭제한 후에 `SELECT *` 사용이 쉽게 발생합니다. 프로그램 BUG

(24) INSERT INTO t_xxx VALUES(xxx) 사용이 금지되어 있으며, 지정된 삽입 열 속성이 표시되어야 합니다

해석: 프로그램 필드를 추가하거나 삭제한 후에 BUG가 나타나기 쉽습니다

(25) 속성 암시적 변환을 사용하는 것은 금지되어 있습니다

해석: `SELECT uid FROM t_user WHERE Phone=13812345678`은 전체 테이블 스캔을 발생시키지만 전화 인덱스에 도달할 수 없습니다. .왜 그럴까요? (이 온라인 질문은 두 번 이상 나타났습니다.)

(26) WHERE 조건의 속성에 함수나 표현식을 사용하는 것은 금지되어 있습니다.

해석: `SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02 -15 ''는 전체 테이블 스캔을 초래합니다

올바른 작성 방법은 다음과 같습니다: `SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00:00')`

(27 ) 부정 질의는 금지되며, %

로 시작하는 퍼지 질의 해석:

* a) 부정 질의 조건: `NOT, !=, <>, !<, !>, NOT IN, NOT LIKE` 등을 사용하면 전체 테이블이 스캔됩니다.

* b) `%`로 시작하는 퍼지 쿼리는 전체 테이블 스캔이 발생합니다.

(28) 대형 테이블에는 JOIN 쿼리를 사용할 수 없으며 하위 쿼리의 사용도 금지됩니다. 대형 테이블의 경우

해석: 임시 테이블이 생성되고 더 많은 메모리와 CPU를 소비하므로 데이터베이스 성능에 큰 영향을 미칩니다

(29) OR 조건 사용은 금지되며 IN 쿼리로 변경해야 합니다

해석: OR 쿼리 이전 버전의 MySQL은 인덱스에 도달할 수 없더라도 데이터베이스가 쿼리 최적화를 구현하는 데 더 많은 시간을 소비해야 합니까?

(30) 애플리케이션은 SQL 예외를 캡처하고 그에 따라 처리해야 합니다.

요약: 데이터 양이 많고 동시성이 높은 인터넷 비즈니스에서는 데이터베이스 성능에 큰 영향을 미치는 것을 사용할 수 없습니다.

추천 학습:

MySQL 튜토리얼

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