minkukjo
commented
2 years ago 스키마 조작
- 온라인 DDL은 스키마를 변경하는 도중에도 다른 커넥션에서 해당 테이블의 데이터를 변경&조회 할 수 있게 해주는 기능이다.
- 주로 DBA분들에게 Production Level의 DDL을 요청하면 Online 모드로 작업해주신다. ( 프로덕션 환경 장애 방지 )
- DDL 알고리즘은 INSTANT -> INPLACE -> COPY 순으로 동작한다. 뒤로갈 수록 더 많은 잠금과 많은 작업을 필요로 한다.
- 책에서는 여러가지 경우의 수를 보여주면서 어떤 알고리즘이 선택되는지 표로 보여주는데, 어차피 봐도 금방 까먹을 것 같아서 대충 스윽 보고 넘김.
- 서버 개발자인 내가 DB 온라인까지 직접 다룰 일은 잘 없다보니 무심하게 넘기게 됐다. (...)
데이터베이스 변경
- 기본적인 데이터베이스 DDL 명령어들이 쭉 나온다.
- 예전에 테이블 DDL을 자동생성해주는 툴을 사용하니까
ENGINE=INNODB라는 키워드가CREATE TABLE구문 끝에 달렸었다. - 리더님이
그거 필요없으니까 없애세요라고 했는데, 영문도 모르고 그냥 지웠었는데, 이제 이 책을 읽고 나니ENGINE과INNODB가 무엇인지 알게 되었다. CREATE TABLE temp_emplyee LIKE employeesLIKE를 붙이면 테이블 구조만 동일하게 복사가 된다고 한다. (오오~)- 인덱스 추가할 때
ALGORITHM=INPLACE붙여주면 잠금 없이 온라인으로 인덱스 생성이 가능하다고 한다. - 8버전에 큰 변화중 하나가 인덱스 가시성 변경이 있다.
- MySQL 서버가 쿼리를 실행할 때 해당 인덱스를 태울지 말지를 결정하는 옵션도 있다고 한다.
ALTER TABLE temp ALTER INDEX ix_firstname INVISIBLE하면 해당 인덱스를 사용안함으로 만들 수 있다고 한다. ( 팀 내에 Boolean 인덱스가 있는데 INVISIBLE 마렵다. )- PK 삭제가 아닌 이상 세컨더리 인덱스 삭제는 테이블 리빌드를 하지 않고 INPLACE 알고리즘을 사용해서 매우 빠르다고 한다.
- 활성 트랜잭션도 조회할 수가 있는데,
information_schema.innodb_trx테이블에서 확인할 수 있다고 한다.
쿼리 성능 테스트
- 쿼리 성능을 확인하는 제일 좋은 방법은 실행 계획을 보는 것이다.
- 그러면 어떤 요소들이 쿼리의 성능에 영향을 미치는지 알아보자.
운영체제의 캐시
- MySQL은 기본적으로 운영체제의 파일 시스템 관련 기능을 시스템콜 해서 데이터 파일을 읽어온다.
- OS의 경우 한 번 읽은 데이터는 캐싱해놓기 때문에 MySQL에서 같은 데이터를 요청하면 OS 캐시에 캐싱된 데이터를 받아온다.
- InnoDB 스토리지 엔진은 OS의 파일 시스템이나 캐시 버퍼를 거치지 않는 Direct I/O 방식(오잉?)을 사용하기 때문에 OS 캐시의 영향을 덜 받는다.
- Direct I/O 방식에 흥미가 생겼다. 왜 OS의 캐시를 이용하지 않는 방식을 취하는걸까?
- https://www.mimul.com/blog/sysvar_innodb_flush_method/
- 아마도 이 책을 읽지 않았다면 위 내용을 하나도 이해못했을 것 같다.
- 위 아티클을 요약하면 InnoDB가 Direct I/O, O_DIRECT를 사용하는 이유는 InnoDB 내부의 버퍼풀을 사용하기 때문에 OS의 이중 캐싱으로 인한 오동작을 피하기 위함으로 보인다.
- 참고로 O_DIRECT는 데이터 파일을 쓰거나, 로그파일을 쓸 때는 fsync를 사용한다고 한다.
버퍼풀
- 데이터파일의 내용을 페이지 단위로 캐싱하는 기능이다.
- InnoDB 스토리지 엔진이 관리하는 캐시를 버퍼풀이라 부른다.
- 인덱스 페이지, 데이터 페이지를 캐시하여 쓰기 작업을 위한 버퍼링 작업까지 겸한다.
Edwin222
DaehunGwak
진도
일시
2022.07.31.(일) 21:00