데일리썽

PK 타입을 생각해보자

int (4바이트)  vs  bigint (8바이트)

• id 값이 약 43억이 넘어가는 아주 큰 DB -> bigint형 사용
• 약 43억 이하의 DB -> int형이 효율적
  
  • int형은 bigint형에 비해 약 10% 이상의 디스크 용량 절약 가능
• 향후 규모가 커질 경우? bigint형 사용
  • 대량의 데이터를 int형에서 bigint형으로 바꾸는데 많은 시간이 걸림

auto increment  vs  UUID(Universally unique id)

• auto increment는 키를 예측하기 쉬움
  • SQL Injection과 같은 공격에 취약
• 여러 DB가 있는 분산환경
  • 동기화가 되어있지 않다면 duplicate key 발생 확률이 높음
• UUID를 사용하자
  • UUID 생성으로 인해 insert 할 때 시간이 더 많이 걸림
  • 128비트 데이터로 충동 가능성이 굉장히 낮음
  • 자바 5 부터 지원

에러:

Caused by: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction

원인:

단일 트랜잭션의 수행 시간이 긴 경우

innodb lock wait timeout 값이 작게 설정된 경우

isolation level의 이슈인 경우

Isolation Level에는 다음의 4가지 단계가 있다.
Read Uncommitted: Transaction이 끝나지 않은 상황에서 다른 Transaction의 변경사항에 대한 조회가 가능하다.
Read Committed: Transaction이 끝나지 않은 데이터에 대한 조회(Select)의 경우 Shared Lock이 발생하며, Commit된 데이터만 조회가 가능하다.
Repeatable Read: Transaction의 Id를 기준으로 생성된 Snapshot 범위 내에서 데이터를 조회하기 떄문에 내용이 항상 동일함을 보장해준다.
Serializable: 가장 엄격한 Isolation Level로 모든 Transaction을 직렬화하여 처리한다.

Repeatable Read는는 첫 SELECT에서 해당 데이터에 Shared Lock을 걸고 데이터의 Shapshot을 생성 및 기록한다.

이후 동일 Transaction내의 SELECT는 Shanpshot에서 읽게 된다.

해결:

트랜잭션 수행 시간이 길다는 것은 비즈니스 로직을 처리하는 과정에서 불필요하게 트랜잭션을 잡았을 수도 있다는 것이다.

반복적으로 timeout이 발생하는 api나 쿼리가 있다면 로직 검토

코드 상의 문제가 없다면 innodb lock wait timeout 값을 변경

SET GLOBAL innodb_lock_wait_timeout=20;

에러:

Packet for query is too large (4,333,196 > 4,194,304). You can change this value on the server by setting the 'max_allowed_packet' variable.; nested exception is com.mysql.cj.jdbc.exceptions.PacketTooBigException: Packet for query is too large (4,333,196 > 4,194,304). You can change this value on the server by setting the 'max_allowed_packet' variable.

원인: 

max_allowed_packet 값은 서버에 전달 또는 서버로부터 받게 되는 패킷의 최대 길이를 나타내는 시스템 변수이다.

현재 max_allowed_packet은 4,194,304Byte로 4MB로 설정되어 있다.

쿼리 길이가 packet에 설정한 최대 길이 제한보다 큰 경우 발생

해결:

max_allowed_packet 설정값 보기

SHOW VARIABLES LIKE 'max%';

max_allowed_packet 값을 8MB로 변경

SET GLOBAL max_allowed_packet = 8388608;

SET SESSION max_allowed_packet = 8388608;

원인 : 연결이 비정상적으로 끊어질 때 해당 횟수를 카운트해서 max_connect_errors보다 같거나 크면 발생한다

해결 :

1. max_connect_errors 값 확인

    select @@global.max_connect_errors;
2. 카운트된 에러 횟수 초기화
     flush hosts;

SET SQL_SAFE_UPDATES =0;

ALTER TABLE `table` AUTO_INCREMENT = 1;
SET @count = 0;
UPDATE `table` SET `filed` = @count:=@count+1;