TIL

오늘 배운 것

혜성 병렬처리 관련 질문

• where절이 없으면 되고 있어도 되는데, 어떤 경우냐면 조건이 인덱스가 없어서 풀스캔 할 경우에만 가능하다.

-책에서CPU 코어수 이상 놓으면 저하된다는데 왜 그럴까. 스레드 작업을 봣을때 io바운드가 높은 작업, cpu 바운드 높은 작업.

io바운드 - 네트워크 디스크 이런거

이런애들은 스레드 수를 늘리는게 이득이다. 대부분은 쉬고잇으니 스위칭하면서하낟.

병렬처리는 CPU바운드가 높다. 대기시간없이 계속 읽는다. 여기서 스레드 수가 더 많아지면, 코어수가 4개인데 8개 스레드를 하게되면, 운영체제가 시분할시스템이라 계속 스위칭을 해주는데, 오히려 더 불편해진다.

-책에서 일반적으로 limit가 성능 높인다고 했는데, 이거 얘시와, 정렬에서 못높이는 예시, 정려렝서 높여줬다면 그 예시

인덱스가 걸린 컬럼에서 읽어오면 뒤에꺼 안읽으니까 성능이 높아진다. 근데 order by

조인할때? 드라이빙 테이블의 컬럼을 통한 limit가 걸린 join이면 드라입이 테이블에서 정렬하고 Limit만큼 붙이니까 정렬에 도움이 된다.

-전문검색할때 n gram에서 크고작고 장단점 n이 작으면 인덱스 커져서 메모리 불리, 대신 검색 정확도 증가.

두환

• select 조회 하고 정렬할때 수천만건 테이블 어떤 정렬이 효율적인지, 그 이유도, 인덱스 정렬

• 쿼리 2개가 있다.

select Count(*) from student

select * from student

이 쿼리를 받았을때 각각 내부적으로 어떻게 처리되는지, 방식이 달라지는 이유.

모든 칼럼을 알아야 하는 여부.

• Sort buffer 질문 책에서 sort buffer 줄이냐 늘리냐 어떨때 효율이 좋냐 이런 얘기. 소트버퍼 크기 무작정 크게 하면 서비스 제공자 입장의 리스크. MySQL 이 꺼질수있다. 소트버퍼라는게 공용공간이 아니라 클라이언트마다 할당되는 공간.

정민

• 학생정보 저장테이블 S id, 일름, 주민번호, 반 컬럼 / id는 PK 반에 인덱스, 주민번호는 Unique,

주민번호를 변경하는 상황과 반을 변경하는 상황 비교해서 설명.

반변경은 인덱스 걸려있다뿐이지 중복이어도 상관없음, 버퍼에 중복여부 체크 안하고 가능 주민번호는 중복이 되면 안되니까 중복 되는지 체크할려고 봐야되서 체인지 버퍼에 저장 안하고 가서 실제로 변경한다. 일반 보조인덱스는 변경속도가 좀 더 빠를것이다.

-똑같은 테이블.

추가테이블 강사 T 사번, 이름, 주민번호, 반 /

두 테이블 물리적 저장방식, 개선할 수 있는거 이유와 설명.

강사는 3가지 조건, 1번 PK 있으면 그걸 PK인덱스로. 2번 없으면 NOn null, unique 로 인덱스 생성 3. 내부적으로 몰래 추가.

개선방안 : 주민번호로 정규화,

• 똑같은 테이블

SELECT * from T,s where T.반==s.반 order t.사번

SELECT * from s,t where s.반==t.반 order s.id

두 쿼리 성능 비교 및 이유

1번은 t.사번으로 Order, 드라이빙 테이블이 t, 근데아무것도 안걸려잇어서 이점이 x 소트버퍼에 t를 다 가져오고 정렬한 후에 이걸 기준으로 s와 비교, filesort발생. - 소트버퍼 들림 2번은 s.id가 pk라 클러스터링, s가 드라이빙, 근데 id가 pk라 인덱스 차례대로 읽으면서 조인 진행, 소트버퍼 x