1. MySQL에서 대소문자(case sensitivity)에 대한 고민
1) Windows vs. Linux 환경 차이
- Windows
- 보통 파일 시스템 자체가 대소문자를 구분하지 않음 (case-insensitive).
- 따라서 Windows 환경에서 MySQL도 디폴트 설정 시 테이블 명/컬럼 명의 대소문자를 엄격하게 구분하지 않습니다.
- Linux
- 파일 시스템이 대소문자를 구분 (case-sensitive).
- 같은 MySQL이라도 Linux 환경에서는 테이블 명/컬럼 명을 대소문자 엄격히 구분하도록 설정되는 경우가 많습니다.
2) MySQL 설정값 확인
MySQL에서는 lower_case_table_names 라는 시스템 변수를 통해 테이블/컬럼명의 대소문자 구분 여부를 설정할 수 있습니다.
sql
코드 복사
SHOW VARIABLES LIKE 'lower%';
- lower_case_file_system: ON이면 파일 시스템이 소문자만 인식(주로 Windows).
- lower_case_table_names:
0→ 구분 O (대문자 ≠ 소문자)1→ 구분 X (대문자 = 소문자)- (Linux에서는 0 또는 2로 설정 가능하지만, 일반적으로 0이 많이 사용됨)
예: lower_case_table_names = 1 이면 테이블 생성 시 대문자를 소문자로 변환해 저장하므로,
CREATE TABLE MyTable과SELECT * FROM mytable이 동일하게 동작합니다.
주의
- 운영환경(특히 Linux)에서
lower_case_table_names가 0으로 설정되어 있으면 테이블명이나 별칭(Alias) 사용 시 대소문자를 정확히 맞춰야 에러가 나지 않습니다.- 반대로 Windows 환경은 보통 1로 설정되어 “대소문자 구분이 없기” 때문에, 개발 환경과 배포 환경이 다르면 예기치 못한 에러가 발생할 수도 있습니다.
2. MySQL 자료형 복습 (정수형 vs. 실수형 vs. 문자형)
2-1. 정수형(INT 계열)
TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT- 필요한 범위와 메모리 사용량을 고려해 선택
UNSIGNED옵션으로 음수를 제외하면 최대값 범위를 2배로 확장 가능
2-2. 실수형(FLOAT, DOUBLE, DECIMAL)
- FLOAT, DOUBLE: 부동소수점. 연산속도 빠르고 큰 범위 표현 가능, 일부 오차 발생
- DECIMAL: 고정소수점. 오차 없이 정밀 계산 가능, 주로 금융 분야에서 사용
2-3. 문자형(CHAR, VARCHAR)
- CHAR(n): 고정 길이. 항상 n바이트를 차지, 길이가 일정한 코드/번호 등에 적합
- VARCHAR(n): 가변 길이. 실제 문자열 길이에 추가 1~2바이트(길이 정보)가 소모, 일반 텍스트에 적합
- 너무 긴 문자열(수천~수만 자)에는
TEXT계열 고려
3. 테이블/컬럼 설계 시 대소문자 이슈 & 자료형 함께 고려하기
- 운영환경(OS)
- 개발/운영 환경이 Windows와 Linux가 다르면, 테이블/컬럼명 케이스 차이로 인해 쿼리 에러가 날 수 있음
- 미리
SHOW VARIABLES LIKE 'lower%';로 설정 확인 후, 프로젝트에 맞춰 통일하는 것이 좋음
- 자료형
- 정수 범위 초과 여부, 소수점 정밀도, 문자열 길이 확정 여부 등을 파악
- 예) “이름” 칼럼은
VARCHAR(50), “우편번호”는CHAR(5)등으로 구분 - 금액이나 환율 같은 민감한 숫자는
DECIMAL(10,2)등 고정소수점 사용을 권장
- 인덱스 및 성능
- 대소문자 구분은 인덱싱에도 영향을 줄 수 있음(특히 Linux 환경)
- 불필요하게 큰 문자형을 지정하면 인덱스 사이즈 커짐 -> 성능 저하
- 실제 데이터 범위를 정확히 파악하고 최적화
4. 정리
- 대소문자 구분: Windows(기본 구분 없음), Linux(구분 있음) 차이를 명심.
- MySQL의
lower_case_table_names값에 따라 다름(0: 구분, 1: 비구분). - 환경이 다른 서버끼리 DB/쿼리를 공유할 땐 더욱 주의.
- MySQL의
- 자료형 선정:
- 정수형/실수형/문자형 고를 때, 데이터 범위와 정밀도, 공간 사용량, 인덱싱을 종합적으로 고려.
- “정말 항상 고정 길이인지, 오차 허용 범위는 어느 정도인지” 등 사전 검토 필수.
TIP: 실제 운영 환경에서 개발 서버(Windows)와 배포 서버(Linux)가 달라서 생기는 케이스 이슈가 매우 흔합니다.
기획 단계에서부터 테이블명은 소문자 통일 등을 권장하며, 설정값도 미리 맞춰두면 혼선을 줄일 수 있습니다.
이처럼 DB 대소문자 구분 문제와 자료형 선택은 모두 운영 환경에 직접적인 영향을 주는 중요한 요소입니다.
프로젝트 초기에 꼼꼼히 체크하고, 일관된 컨벤션(테이블명·컬럼명 소문자 통일 등)을 지키면 유지보수가 훨씬 수월해집니다.
