[DB] Charset & Collation

Charset & Collation

Charset(문자 집합)과 Collation(정렬 규칙)은 데이터베이스에서 문자열을 저장하고 정렬하는데 사용되는 중요한 속성이다.

Charset

• Charset은 데이터베이스에서 사용되는 문자의 인코딩 방식을 나타낸다.
• 각 문자는 특정한 코드로 표현되며, Charset은 이러한 문자 코드 집합을 결정한다.
• UTF-8, UTF-16, Latin1 등이 흔한 Charset이다.
• Charset을 선택하는 것은 데이터베이스에서 어떤 언어를 지원할 것인지와 관련이 있다.

UTF8(UTF8mb3) vs UTF8mb4

UTF8은 가변 길이 인코딩이다. 원래 UTF8은 하나의 글자를 저장하려면 1~4byte를 사용하도록 설계되었다. 하지만 MySQL의 기본 UTF8은 UTF8mb3으로 설계되어 있는데 그 이유는 해당 시기에는 4byte를 다 쓰는 문자가 거의 없었고, 그래서 속도를 빠르게 하기 위해 이렇게 설계해 두었다고 한다.

따라서 4byte 문자가 허다하게 쓰이는 지금은 큰 이유가 있지 않은 이상(BMP 문자 외에는 절대 database에 저장되지 않는다는 확신이 있는 등) UTF8mb4 Charset을 사용하는게 맞다.

Collation

• Collation은 문자열을 정렬할 때 사용되는 규칙을 정의한다.
• 데이터베이스에서 문자열 값을 정렬하는데 특정한 규칙을 사용해야한다. 이는 각 문자의 상대적인 순서를 결정하는 방식이다.
• 대소문자 구분 여부, 알파벳 순서, 비교 연산 등을 정의한다.

general vs unicode

Collation에는 다양한 방식이 존재하지만, 보통 우리가 사용하는 것은 general과 unicode이다.

• general

  • 속도 향상을 위해 설계된 다양한 방법을 사용하며 최대한 잘 작동하도록 단순화된 방식이다. 이는 유니코드 규칙을 따르지 않으며, 특정 언어나 문자를 사용하는 경우 바람직하지 않은 정렬 또는 비교 결과가 도출 될 수 있다.

• unicode

  • 공식 유니코드 규칙을 기반으로 한 범용 정렬 및 비교를 위한 방식으로, 다양한 언어에서 정확하게 작동한다.

둘의 주요 차이점은 속도이다. CPU 성능이 좋지 않았던 과거에는 해당 알고리즘의 차이가 속드를 크게 좌우해서 완벽한 정렬이 필요할때를 제외하고는 general을 사용하는게 맞았다고 한다. 현재 CPU 성능이 크게 높아진 지금에 와서는 속도가 유의미한 차이를 보이지 않아 unicode를 사용하는게 좋다.

아래는 50만개의 데이터가 있는 table에서의 속도 비교이다.

simple select (3.2%)
general : 9.957ms
unicode : 10.271ms

select like (12%)
general : 11.441ms
unicode : 12.811ms

order by (7.9%)
general : 11.944ms
unicode : 12.887ms

ci, cs, bin

Collation 가장 마지막에 붙는 ci, cs, bin은 collation에 따라 문자열을 비교하는 방식을 나타낸다.

• ci (case-insensitive)
  • 대소문자를 구분하지 않는 문자열 비교를 수행한다. 즉, A와 a는 같은 문자로 처리된다.
• cs (case-sensitive)
  • 대소문자를 구분하여 문자열 비교를 수행한다. 즉, A와 a는 다른 문자로 처리된다.
• bin (binary)
  • 이진(binary) 비교를 수행한다. 이진 비교는 문자열을 이진 값으로 변환하여 비교하는 방식으로, 대소문자를 구분한다. 이 방식은 문자열의 정확한 바이트 값으로 비교를 수행하므로 정확한 비교 결과를 얻을 수 있다.