issues
search
DaehunGwak
/
study-real-mysql-2
4
stars
0
forks
source link
6. 스토어드 프로그램 (~14.4), 데이터 타입 (~15.5)
#10
Open
DaehunGwak
opened
2 years ago
DaehunGwak
commented
2 years ago
진도
스토어드 프로그램 (14.3, 14.4)
데이터 타입 (~15.5 TEXT와 BLOB)
일시
2022.08.21.(일) 21:00
minkukjo
commented
2 years ago
스토어드 프로그램
지난 시간에 끝까지 다 읽는 건 줄 알고 실수로 다 읽어서 이 부분은 패스
데이터 타입
가변 길이 컬럼은 최적의 크기를 지정하는 편이 좋다.
조인 조건으로 사용되는 컬럼은 같은 데이터 타입으로 설정해두자. ( 이거 놓치면 꽤나 성능저하가 있음 )
저장되는 값의 성격에 맞는 최적의 타입을 선정하자.
문자열 데이터타입 CHAR, VARCHAR
CHAR, VARCHAR의 차이는 고정 길이냐 가변 길이냐의 차이다.
CHAR, VARCHAR를 선택하는 기준은, 두 가지이다.
저장되는 문자열의 길이가 대게 비슷한 편인지? ( like ENUM )
칼럼의 값이 자주 변경되는지? ( like ENUM )
VARCHAR의 경우 첫 번째 바이트에 문자열의 길이를 저장하고, 두 번째부터 첫번째 바이트에 저장된 길이 만큼 문자를 저장하게 된다.
문제는 이 VARCHAR의 길이가 변경될 경우 ( 만약 더 커진다면 ) 현재 위치한 공간이 아닌 다른 공간으로 옮기는
Row Migration
과정이 필요하다.
CHAR의 경우 고정 길이를 잡고 시작하기 때문에 데이터 타입 크기안에서는 자유롭게 값이 바뀌어도 괜찮다.
그래서 주민등록번호처럼 값이 고정적인 경우에는
CHAR
를 사용하는게 유리하다.
또한 값이 2~3바이트 차이가 나더라도 자주 변경될 수 있는 부서 번호나, 상태 값과 같은
ENUM
값들은
CHAR
를 사용하는게 좋다고 한다.
Collation
문자열 컬럼의 값 비교나 정렬 순서를 위한 규칙
비교나 정렬 작업에서 영문 대소문자를 같은 것으로 볼지, 더 크거나 작은 것으로 볼지와 같은 규칙
콜레이션에 따라 쿼리 성능이 상당한 영향을 받을 수 있다고 한다.
문자열 컬럼의 비교는 CHAR, VARCHAR같은 타입의 이름과 길이만 같다고 똑같은게 아닌 Collation까지 같아야 비로소 같은 타입이라고 할 수 있다.
문자 집합이나 Collation은 DB 수준에서도 설정할 수 있고, 테이블 별로도 설정 가능. 그리고 컬럼 수준에서도 설정이 가능하다.
비교 방식
CHAR냐 VARCHAR냐에 따라 비교 방식이 달라지지는 않고 거의 같다.
그런데 utf8mb4 문자 집합이 UCA 9.0.0을 지원하면서 문자열 뒤에 공백을 처리하는 방식이 달라졌다.
기존에는 문자열 뒤에 붙어있는 공백은 쿼리에 영향을 주지 않았지만, 9.0.0부터는 공백이 쿼리에 영향을 미치게 되니 조심하도록 하자.
숫자
대부분 알고 있는 내용들이라 패스
날짜와 시간
Now
() 메소드안에 숫자를 넣으면 그 숫자 만큼 밀리초를 반환해준다고 한다( 대박 )
Datetime의 경우 타임존이 적용되지 않는데, JDBC API나 하이버네이트에서 변환과정을 거쳐서 실제 코드에서는 Timestamp와 동일하게 타임존 변환이 가능하다고 한다.
ENUM과 SET
ENUM을 가지는 테이블을 만들어서 쓸 수 있다는데.. 이런건 그냥 애플리케이션에서 하자;
SET도 쓰지 말자 이런건..
TEXT와 BLOB
대량의 데이터 저장에 쓰이는 타입이다.
TEXT는 문자열을 저장하는 대용량 컬럼이라 문자 집합이나 컬레이션을 갖고, BLOB은 이진 데이터 타입이라 별도의 문자 집합이나 컬레이션을 갖지 않는다.
DaehunGwak
commented
2 years ago
note
14. 스토어드 프로그램 (14.3, 14.4)
15. 데이터 타입 (15.1 ~ 15.5)
진도
일시
2022.08.21.(일) 21:00