복습편-mysql
1.
2.
3.
4.
Mysql의 메모리 엔진, myisam과 innodb의 차이점:
1.MyISAM ， 。 ， ， ， 。
2.innodb ， ， （ ）， ， 。
데이터베이스 인덱스 키와 유일한 인덱스는 어떤 차이가 있습니까
1. ，
2. ，
3. ，
4. ，
5. ，
MySQL 행 잠금이 꺼져 있는 경우가 있습니까?
， 。
1. mysql ， 。
2. sql
집합 인덱스와 비집합 인덱스의 차이
1.( )
2.( )
innoDB의 B+트리 인덱스 잎 노드의 Data역은 무엇을 저장합니까?
MyISAM의 B+ 트리 인덱스 잎 노드의 Data 도메인에 기본 키가 저장됩니까? 아니면 물리적 주소가 저장됩니까?
데이터베이스의 기본 특징은?
、 、
어떻게 당신의 ql문장이 인덱스에 사용되었는지 판단합니까?
실행 계획 EXPLAIN 보기
explain(실행계획)에 포함된 정보는 매우 풍부하므로 다음과 같은 몇 개의 필드 정보를 주목합니다.
1. id,select 자문 또는 표 실행 순서, id가 같고 위에서 아래로 실행됩니다. id가 다르면 id 값이 클수록 실행 우선순위가 높습니다.2. type, type의 주요 수치와 sql의 좋고 나쁨을 나타내는 정도(좋은 것부터 나쁜 것까지): 시스템>const>eqref>ref>range>index>ALL.보증range,ref까지.3. 키, 실제 사용되는 색인 열.4.ref, 관련 필드, 상수 등 값 조회,const로 표시되며, 연결 조회를 위해 관련 필드를 표시합니다.5.extra, 추가 정보, 우선 순위 Using index>Using filesort(구사일생)>Using temporary(십사무생)를 사용합니다.
우선 순위 Using index>Using filesort(구사일생)>Using temporary(십사무생)를 사용합니다.바로 다음 두 항목이 나타나면 sql문장이 매우 엉망이라는 것을 나타낸다. 최적화가 급히 필요하다!!!
sql 최적화 주의사항:
① 최고의 왼쪽 접두사 법칙.
1. ， ， explain ， mysql 。
2. order by ， 、 ， Using filesort 。
② group by는 Using temporary를 쉽게 생성합니다.
③ 통속적 이해 구결:
전치가 내가 가장 좋아하는 것과 일치하고 왼쪽 접두사는 준수해야 한다.앞장서는 형은 죽을 수 없고, 중간에 형제는 끊어질 수 없다.색인열에 계산을 적게 하고 범위 이후에는 모두 효력을 상실합니다.LIKE는 맨 오른쪽으로 쓰고 색인을 덮어쓰고 별을 쓰지 않습니다.부등공치 or, 인덱스 실효는 적게 사용합니다.
mysql 필드 형식?
char ， ， ，
vachar ，
한 표에 여러 개의 색인이 있습니까?
16
mysql는 어떻게 최적화합니까?
1.
2. EXPLAIN
3. sql 108
4.show profile 15 (Show Profile mysql sql ， sql 。 ， 15 。)
show profile all,block all for query X；
mysql 자물쇠?
1.
2.
3. , ， ，
4. ( ，mysql + ， )
mysql 어떻게 한 줄만 잠그나요?
for update
ps: select * from student s where s.name = 'zhangsan' for update;
mysql 잠금 최적화 제안:
① ， 。
② ， 。
③ ， 。
④ ， 。
⑤ 。
주종 복제의 기본 원리:
①master （binary log）， （binary log events）。
②slave master binary log events （relay log）。
③slave ， 。MySQL 。
：1
작은 테이블이 큰 테이블을 제어합니다.
in ，exists 。
：in ，exists 。
ps: select *from tb_emp_bigdata A where A.deptno in (select B.deptno from tb_dept_bigdata B) (A ，B )
ps: select *from tb_dept_bigdata A where exists(select 1 from tb_emp_bigdata B where B.deptno=A.deptno); (A ，B )
라이브러리별 테이블:
： ，
라이브러리 테이블의 중간부분:
sharding-jdbc：sharding-jdbc client ， ， ，
mycat：mycat proxy ， ， ， ，
라이브러리 테이블을 나누는 방법:
1. range ， ， ， ， ，
2. hash ， ， ； ， ， hash
데이터 마이그레이션 시나리오:
1.
2. （1. ，2. ，3. ，4. ，5. ， 50 hash， ）
어떻게 동적 용량 확장과 축소를 할 수 있는 라이브러리 리스트 방안을 설계합니까?
%32 ， ，
라이브러리 리스트 이후 id 메인 키는 어떻게 처리합니까?
1. id （ redis id ，redis ）
2. sequence
3.UUID
4.
분고 분표 후 어떻게 페이지를 나누어 조회합니까?(신규 제목)
1. 글로벌 시야법: N페이지의 데이터(매 페이지 S조의 데이터)를 얻으려면 각 하위 라이브러리의 앞 N페이지(offset 0,limit N*S)의 모든 데이터를 먼저 찾아내고(선별 조건이나 정렬 규칙이 있으면 포함) 각 하위 라이브러리의 결과를 합친 후,다시 우리가 평소에 일반적인 페이지 조회를 하면 (같은 선별 조건을 가지지 않아도 되지만 정렬 규칙도 가지고) 최종 결과를 얻을 수 있다. 이런 방식은es페이지의 논리와 유사하다.장점: 데이터가 정확하고 페이지를 뛰어넘을 수 있는 단점: 깊이 페이지를 나눌 때의 성능이 떨어진다. 즉, 페이지 파라미터가 증가함에 따라 네트워크 전송 데이터의 양이 점점 커지고 각 하위 테이블마다 조회해야 할 데이터가 많을수록 성능도 느려진다.
2. 페이지 나누기 금지법: N페이지의 데이터를 얻으려면 첫 페이지는 전역시야법과 일치하지만 두 번째 페이지가 시작된 후에 모든 하위 라이브러리에서 조회해야 할 때이전 페이지의 필터 조건을 제외할 수 있습니다 (예를 들어 시간별로 정렬할 때 이전 페이지의 최대 시간을 가져오면 time > ${maxTime lastPage} 조건을 추가해야 합니다. 정렬 규칙이 없으면 기본 키 id의 정렬 규칙이기 때문에 id > ${maxId lastPage} 조건을 추가해야 합니다.) 그리고 limit S를 추가하면 각 하위 라이브러리의 결과를 얻을 수 있습니다.나중에 합병하면 탑S가 최종 결과를 얻을 수 있다.유사한 앱의 목록 밑에 있는 장면에서는 업무상 페이지 조회를 금지할 수 있으며 이럴 때 이런 방식을 사용할 수 있다.장점: 데이터가 정확하고 성능이 양호하며 단점: 페이지를 뛰어넘을 수 없다
4. 모호한 조회법 등: 모호한 조회법은 조회 결과가 정확하지 않기 때문에 편집자가 종합하지 않아서 관심 있는 친구가 스스로 연구할 수 있다.
좋은 웹페이지 즐겨찾기
