MySQL 8.0.29 OnlineDDL

OnlineDDL 확인사항

1. MySQL 8.0.29의 Online DDL
   1. Engine type이 innodb인 경우만 가능하다.
   2. ALTER TABLE 명령을 실행하면 MySQL서버는 다음 순서로 스키마 변경에 적합한 알고리즘을 찾는다
      1. ALGORITHM=INSTANT로 스키마 변경이 가능한지 확인 후, 가능하다면 선택
      2. ALGORITHM=INPLACE로 스키마 변경이 가능한지 확인 후, 가능하다면 선택
      3. ALGORITHM=COPY로 스키마 변경이 가능한지 확인 후, 가능하다면 선택
       
   3. LOCK 수준이 명시되지 않으면 MySQL서버가 적절한 수준의 잠금 수준을 선택
      1. INSTANT는 메타데이터만 변경하기 때문에 짧은 시간의 메타데이터 잠금만 필요로 하므로 LOCK을 명시할수 없다.
      2. INPLACE 및 COPY 알고리즘을 사용하는 경우 LOCK은 3가지중 하나를 명시할 수 있다.
         1. NONE : 아무런 잠금을 걸지 않음
         2. SHARED : 읽기 잠금을 걸고 스키마 변경수행, 스키마 변경중 읽기는 가능하나 쓰기(INSERT,UPDATE,DELETE) 불가능
         3. EXCLUSIVE : 쓰기 잠금을 걸고 스키마 변경수행, 테이블 읽고 쓰기 불가능
   4. Online 스키마 변경 작업 진행 동안 DML을 메모리에 로깅하고 변경 완료후 DML로깅을 테이블에 적용
      1. innodb_online_alter_log_max_size 초과시 작업 실패 및 Rollback

1. Intant

테이블 데이터는 전혀 변경하지 않고, 메타데이터만 변경하고 작업을 완료한다. 
스키마 변경 도중에 읽기쓰기는 대기하지만 작업시간이 매우 짧기 때문에 
다른 커넥션의 쿼리 처리에는 영향을 미치지 않는다.

2. inplace

임시테이블로 데이터를 복사하지 않고 스키마 변경을 수행한다. 
하지만 내부적으로는 table rebuild(또는 데이터 재구성 이라고도 함)를 수행할 수도 있다. 
레코드의 복사 작업은 없지만 테이블의 모든 레코드를 리빌드 해야 하기 때문에 
테이블에 크기에 따라많은 시간이 소요될 수도 있다.

-> 하지만 스키마 변경 중에도 테이블의 읽기와 쓰기가 모두 가능하다.
-> inplace 알고리즘으로 스키마가 변경되는 경우에도 최초 시작과 마지막 종료 지점에는 
테이블의 읽기 쓰기가 불가능 하다. 
하지만 이 시간은 매우 짧아서 다른 커넥션의 쿼리 처리에 대한 영향도는 높지 않다.

- 데이터 재구성이 필요한 경우 : 
잠금을 필요로 하지 않기 때문에 DML은 가능하지만 레코드 건수에 따라 상당히 많은 시간이 소요될 수도 있다.(프라이머리 키 추가 작업 → 데이터파일에서 레코드의 저장 위치가 바뀌어야 하기 때문에)
- 데이터 재구성이 필요치 않은 경우 : 
inplace 알고리즘을 사용하지만 INSTANT알고리즘과 비슷하게 매우 빨리 작업이 완료될 수 있다. 
( 컬럼의 이름만 바뀌는 경우 등)

3.copy
변경된 스키마를 적용한 임시 테이블을 생성하고, 
테이블의 레코드를 모두 임시 테이블로 복사한 후 
최종적으로 임시 테이블을 RENAME해서 스키마 변경을 완료한다. 
-> 이 방법은 테이블 읽기만 가능하고 DML은 실행할 수 없다