MySQL 의 21 개 규범,최 적 실천 최적화!
모든 좋 은 습관 은 하나의 자산 입 니 다.본 고 는 SQL 후회 약,SQL 성능 최적화,SQL 규범 우아 세 가지 방향 으로 나 뉘 어 SQL 을 쓰 는 21 가지 좋 은 습관 과 가장 좋 은 실천 을 공유 합 니 다!
SQL 을 작성 하고 실행 계획 을 먼저 설명 합 니 다(SQL 성능 최적화)
SQL 을 일상 적 으로 개발 할 때 가능 한 한 좋 은 습관 을 기 르 도록 하 세 요.SQL 을 다 쓴 후에 explain 으로 분석 해 보 세 요.특히 색인 을 걷 지 않도록 주의 하 세 요.
delete 또는 update 문 구 를 조작 하고 limit(SQL 후회 약)을 추가 합 니 다.
삭제 또는 업데이트 문 구 를 실행 할 때 limit 를 추가 하고 다음 SQL 을 예 로 들 어 보 세 요.
delete from euser where age > 30 limit 200;
제한 을 넣 으 면 주로 이런 장점 이 있 기 때문이다.
1.SQL 을 잘못 쓰 는 대 가 를 낮 춥 니 다.명령 행 에서 이 SQL 을 실행 할 때 limit 을 추가 하지 않 고 실행 할 때 손 이 떨 리 면 데이터 가 모두 삭 제 될 수 있 습 니 다.잘못 삭제 하면 요?limit 200 을 넣 으 면 달라 집 니 다.삭제 오류 도 200 개의 데 이 터 를 잃 어 버 렸 을 뿐 binlog 로 그 를 통 해 빠르게 복구 할 수 있 습 니 다.
2.SQL 의 효율 이 더 높 을 수 있 습 니 다.SQL 줄 에 limit 1 을 추 가 했 습 니 다.첫 번 째 항목 이 목표 return 에 명중 하고 limit 이 없 으 면 스 캔 표를 계속 실행 할 것 입 니 다.
3.긴 업 무 를 피하 고 delete 가 실 행 될 때 age 에 색인 을 추가 하면 MySQL 은 관련 된 모든 줄 에 쓰기 자물쇠 와 간극 자 물 쇠 를 추가 하고 모든 실행 관련 줄 이 잠 겨 있 으 며 삭제 수량 이 많 으 면 관련 업무 에 직접적인 영향 을 줄 수 있 습 니 다.
4.데이터 양 이 많 으 면 CPU 를 채 우기 쉽 습 니 다.데 이 터 를 많이 삭제 할 때 limit 을 넣 지 않 고 기록 수 를 제한 하지 않 으 면 cpu 를 채 우기 쉬 워 서 삭제 가 느 려 집 니 다.
표를 디자인 할 때 모든 표 와 필드 에 해당 하 는 주석 을 추가 합 니 다(SQL 규범 이 우아 합 니 다)
이 좋 은 습관 은 반드시 길러 야 한다.데이터 베 이 스 를 디자인 할 때 모든 표 와 필드 에 해당 하 는 주석 을 추가 하고 그 다음 에 유지 하기 쉽다.
정규:
CREATE TABLE `account` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT ' Id',
`name` varchar(255) DEFAULT NULL COMMENT ' ',
`balance` int(11) DEFAULT NULL COMMENT ' ',
`create_time` datetime NOT NULL COMMENT ' ',
`update_time` datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT ' ',
PRIMARY KEY (`id`),
KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT=' ';
반 례:
CREATE TABLE `account` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`balance` int(11) DEFAULT NULL,
`create_time` datetime NOT NULL ,
`update_time` datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8;
SQL 쓰기 형식,키워드 크기 일치,들 여 쓰기 사용(엘 레 강 스 SQL정규:
SELECT stu.name,sum(stu.score)from Student stuWHERE stu.classNo='1 반'그룹 BY stu.name
반 례:
SELECT stu.name,sum(stu.score)from Student stu.classNo='1 반'group by stu.name.
분명 한 것 은 키워드 의 대소 문자 가 일치 하고 들 여 쓰기 정렬 을 사용 하면 SQL 이 더욱 우아 해 보일 것 입 니 다~
INSERT 문 구 는 대응 하 는 필드 이름 을 표시 합 니 다(SQL 은 우아 합 니 다)
반 례:
학생 값 에 삽입('666','아마추어 풀','100');
정규:
insert into Student(student_id,name,score)values('666','아마추어 풀','100');
SQL 작업 을 변경 하려 면 먼저 테스트 환경 에서 실행 하고 상세 한 작업 절차 와 스크롤 백 방안 을 작성 하 며 생산 전에 review 를 작성 합 니 다.(SQL 후회 약)
4.567917.SQL 작업 을 변경 하려 면 먼저 테스트 환경 테스트 를 하고 문법 오류 가 발생 하지 않도록 생산 에 두 어야 한다
반 례:
CREATE TABLE `account` (
`name` varchar(255) DEFAULT NULL COMMENT ' ',
`balance` int(11) DEFAULT NULL COMMENT ' ',
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT=' ';
정규:
CREATE TABLE `account` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT ' Id',
`name` varchar(255) DEFAULT NULL COMMENT ' ',
`balance` int(11) DEFAULT NULL COMMENT ' ',
`create_time` datetime NOT NULL COMMENT ' ',
`update_time` datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT ' ',
PRIMARY KEY (`id`),
KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT=' ';
이유:1.메 인 키 는 반드시 추가 해 야 합 니 다.메 인 키 가 없 는 시 계 는 영혼 이 없습니다.
2.생 성 시간 과 업데이트 시간 은 추가 하 는 것 을 권장 합 니 다.상세 한 감사,추적 기록 은 모두 유용 합 니 다.
아 리 개발 매 뉴 얼 도 이 점 을 언급 했다.그림 과 같다.
SQL 문 구 를 작성 하고 where,orderby,group by 뒤의 열 을 검사 합 니 다.다 중 표 와 연 결 된 열 에 색인 이 추가 되 었 는 지 확인 하고 조합 색인 을 우선 고려 합 니 다.(SQL 성능 최적화)
반 례:
정규:
--색인 alter table user add index idx 추가address_age (address,age)
중요 한 데 이 터 를 수정 하거나 삭제 하기 전에 백업 을 해 야 합 니 다.백업 을 먼저 하고 백업 을 먼저 해 야 합 니 다.(SQL 후회 약)
데 이 터 를 수정 하거나 삭제 하려 면 SQL 을 실행 하기 전에 수정 할 데 이 터 를 백업 해 야 하 며,잘못 조작 하면 후회 하 는 약 을 먹 을 수 있다.
where 뒤의 필드,데이터 형식의 암시 적 변환(SQL 성능 최적화)에 주의 하 십시오.
반 례:
//userid 는 varchar 문자열 형식 select*from user where userid=123;
정규:
select * from user where userid ='123';
이유:
따옴표 가 추가 되 지 않 을 때 문자열 과 숫자 를 비교 하기 때문에 형식 이 일치 하지 않 습 니 다.MySQL 은 암시 적 인 형식 으로 변환 하여 부동 소수점 으로 변환 한 다음 에 비교 하면 색인 이 실 효 됩 니 다.
가능 한 한 모든 열 을 NOT NULL 로 정의 합 니 다.(SQL 은 우아 합 니 다.)
NOT NULL 열 은 공간 을 더욱 절약 합 니 다.NULL 열 은 NULL 인지 아 닌 지 를 판단 하 는 추가 바이트 가 필요 합 니 다.
NULL 열 은 빈 포인터 문 제 를 주의해 야 합 니 다.NULL 열 은 계산 과 비교 할 때 빈 포인터 문 제 를 주의해 야 합 니 다.
SQL 을 수정 하거나 삭제 하려 면 먼저 WHERE 를 써 서 확인 하고 확인 한 후에 delete 나 update(SQL 후회 약)를 보충 합 니 다.
특히 생산 된 데 이 터 를 조작 할 때 수정 되 거나 삭 제 된 SQL 이 발생 하면 where 조 회 를 추가 하고 OK 를 확인 한 다음 update 또는 delete 작업 을 수행 합 니 다.
select 대신 select<구체 적 인 필드>를 사용 하 는 등 불필요 한 필드 반환 을 줄 입 니 다*(SQL 성능 최적화)
반 례:
select * from employee;
정규:
select id,name from employee;
이유:
자원 을 절약 하고 네트워크 비용 을 줄이다.
덮어 쓰기 색인 을 사용 하여 리 턴 을 줄 이 고 조회 효율 을 높 일 수 있 습 니 다.
모든 표 는 Innodb 메모리 엔진 을 사용 해 야 합 니 다(SQL 은 우아 합 니 다)
Innodb 는 업 무 를 지원 하고 줄 잠 금 을 지원 하 며 더 좋 은 회복 성 을 가 집 니 다.높 고 성능 이 좋 습 니 다.그래서 특별한 요구(즉,Innodb 가 만족 할 수 없 는 기능,예 를 들 어 열 저장,공간 데이터 저장 등)가 없 는 경우 모든 표 는 Innodb 저장 엔진 을 사용 해 야 합 니 다.
데이터베이스 와 표 의 문자 집합 은 UTF 8 을 통일 적 으로 사용 합 니 다(SQL 은 우아 합 니 다)
UTF 8 인 코딩 통일 사용
4.567917.난 코드 문 제 를 피 할 수 있다.
4.567917.서로 다른 문자 집합 이 비교 전환 되 어 색인 실효 문 제 를 피 할 수 있 습 니 다.
표정 을 저장 하 는 것 이 라면,utf8mb 4 를 고려 할 수 있다.
char 대신 varchar 를 사용 하 십시오.(SQL 성능 최적화)
반 례:
`deptName`char(100)DEFAULT NULL COMMENT'부서 명'
정규:
`deptName`varchar(100)DEFAULT NULL COMMENT'부서 명'
이유:
먼저 필드 가 길 어 지고 저장 공간 이 작 아 지면 저장 공간 을 절약 할 수 있 기 때문이다.
필드 의 의 미 를 수정 하거나 필드 에 표 시 된 상태 가 추가 되면 필드 설명 을 제때에 업데이트 해 야 합 니 다.(엘 레 강 스 SQL
이 점 은 아 리 개발 매 뉴 얼 에서 Mysql 의 규약 입 니 다.필드,특히 매 거 진 상 태 를 표시 할 때 의미 가 수정 되 거나 상태 가 추가 되 었 을 때 뒤에 더 잘 유지 되 기 위해 서 는 필드 의 설명 을 즉시 업데이트 해 야 합 니 다.
SQL 에서 데 이 터 를 수정 하여 begin+commt 업무 습관 을 기 릅 니 다.(SQL 후회 약)
정규:
begin;update account set balance=1000000 where name='아마추어 풀';commit;
반 례:
update account set balance=1000000 where name='아마추어 풀';
색인 이름 은 규범화 되 어야 합 니 다.메 인 키 색인 이름 은 pk 입 니 다.필드 이름;유일한 색인 이름 은 uk필드 이름;일반 색인 이름 은 idx필드 이름.엘 레 강 스 SQL
설명:pk즉,primary key;uk _ 즉 고유 키;idx _ index 의 약칭.
WHERE 는 문장 에서 열 에 따라 함수 변환 과 표현 식 계산 을 하지 않 습 니 다.
loginTime 에 색인 을 추가 했다 고 가정 합 니 다.
반 례:
select userId,loginTime from loginuser where Date_ADD(loginTime,Interval 7 DAY) >=now();
정규:
explain select userId,loginTime from loginuser where loginTime >= Date_ADD(NOW(),INTERVAL - 7 DAY);
업데이트 데 이 터 를 너무 많이 수정 하면 일괄 진행 을 고려 합 니 다.
반 례:
delete from account limit 100000;
정규:
for each(200 회){delete from account limit 500;}
이유:
4.567917.대량의 작업 은 주종 지연 을 초래 할 수 있다4.567917.조작 은 큰 사무,차단 이 생 길 수 있다4.567917.양 조작,데이터 양 이 너무 많 으 면 cpu 를 가득 채 울 수 있 습 니 다이상 의 내용 은 독자 의 프로 그래 밍 에 도움 이 되 기 를 바 랍 니 다!
MySQL 에 관 한 21 가지 규범,최 적 실천 최적화!의 글 은 여기까지 소개 합 니 다.더 많은 관련 MySQL 규범 최적화 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 저 희 를 많이 사랑 해 주세요!
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Redash를 사용할 때 몰랐던 SQL을 쓰는 법을 배웠습니다.최근 redash에서 sql을 쓸 기회가 많고, 이런 쓰는 방법이 있었는지와 sql에 대해 공부를 다시하고 있기 때문에 배운 것을 여기에 씁니다. Redash란? 월별로 데이터를 표시하고 싶습니다 주별로 데이터를 표...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.