칼럼변경
테이블 구조 변경 작업은 대부분 칼럼을 추가하더나 칼럼 타입을 변경하는 작업
ALTER TABLE 명령을 이용
칼럼추가
INPLACE 알고리즘을 사용한 온라인 DDL 처리, 마지막 칼럼 추가는 INSTANT 알고리즘으로 바로 추가 가능
테이블이 큰 경우 칼럼을 마지막에 추가하는거시 좋음
칼럼 삭제
칼럼을 삭제하는 과정은 항상 테이블 리빌드를 필요로 하기 때문에 INSTANT 알고리즘을 사용할 수 없음
항상 INPLACE 알고리즘을 이용해 칼럼 삭제 가능
칼럼 이름 및 칼럼 타입 변경
칼럼값의 저장용 공간은 칼럼의 값의 바이트 수가 255 이하인 경우 1바이트만 사용하고, 256 이상 사용시 2바이트를 사용함
칼럼 최대값 변경시 1바이트 이하테이블 리빌드가 필요없지만, 1바이트에서 2바이트로 변경시 테이블 리빌드가 필요함
인덱스 변경
전문 검색 인덱스와 공간 검색 인덱스를 제외하면 나머지 인덱스는 모두 B-Tree 자료구조를 사용함
전문 검색 인덱스와 공간 검색 인덱스는 INPLACE 알고리즘으로 인덱스 생성이 가능하지만, SHARD잠금이 필요함
B-Tree 자료구조를 사용하는 인덱스 추가는 잠금없이 온라인으로 인덱스 생성이 가능함
인덱스 조회
SHOW INDEXES
테이블의 인덱스만 표시
칼럼별로 한줄씨 표시
SHOW CREAT TABLE
테이블의 생성 구문을 그대로 보여줌
인덱스 별로 한줄로 표시 하고, 인덱스에 어떤 칼럼이 어떤 순서로 있는지 파악하기 쉬움
인덱스의 가시성 변경
인덱스를 삭제하는 작업은 ALTER DRP INDEX 로 즉시 완료 되지만, 한번 삭제된 인덱스를 새로 생성하는 것은 매우 많은 시간이 걸릴 수 있음
인덱스를 삭제했는데 다시 적용할 수 있기 때문에 INVISBLE을 이용하여 인덱스를 ON OFF 하여 확인 후 삭제하는것도 좋은 방법
근데 인덱스 차이로 왜 ROW 차이가 나는거임?
인덱스를 처음 생성 할 때는 INVISIBLE로 생성하고 부하가 낮은 시점에 VISIBLE로 변경해서 인덱스를 적용했다가
서버에 부하가 생기면 다시 INVISIBLE로 변경해서 원인을 고민하는것도 좋음
인덱스 삭제
ALTER TABLE ... DROP INDEX ... 명령으로 인덱스 삭제
테이블 변경 묶음 실행
하나의 테이블에 대해 여러가지 스키마 변경을 하는 경우 개별 ALTER TABLE 명령을 치기도 하지만, 한번에 모아서 처리 할 수 있음
한번에 처리한다면 테이블의 레코드를 한번만 풀스캔하여 2개의 인덱스를 한꺼번에 생성 할 수 있음
프로세스 조회 및 강제 종료
SHOW PROCESSLIST
서버에 접속된 사용자의 목록이나 각 클라이언트 사용자가 현재 어떤 쿼리를 실행하고 있는지 알 수 있음
대부분의 프로세스 Command 칼럼이 Sleep 상태 이겠지만, 오랜시간을 잡고 있는 쿼리가 있다면 확인할 필요가 있음
KILL QUERY 1 은 쿼리만 종료하고 커넥션은 남아있음
KILL 1은 커넥션까지 종료시킴(트렌젝션이면 롤백함)
활성 트랜젝션 조회
트랜젝션이 5초 이상 활성 상태로 남아있는 프로세스만 조사하는 쿼리
170초 동안 트랜젝션이 유지 되는 중
쿼리 성능 테스트
쿼리 성능에 영향을 미치는 요소 -> 가장 큰 요소는 버퍼, 캐시
운영체제가 관리하는 캐시나 버퍼는 공용공간이기 때문에 MySQL 서버와 같은 프로그램이 종료된다고 해도 여전히 남을 수 있음
캐시나 버퍼가 없는 상태에서 테스트를 하려면 운영체제의 캐시나 버퍼를 지우고 테스트를 진행해야 함
InnoDB 스토리지 엔진이 관리하는 캐시를 버퍼 풀이라고 하며, 인덱스 페이지, 데이터 페이지 까지 캐시하며, 쓰기 작업을 위한 버퍼링 작업까지 겸해서 처리함
MySQL 서버에 포함된 키 캐시나 버퍼 풀을 초기화 하려면 MySQL 서버를 재시작 해야함