11.2.3 Identifier Case Sensitivity

11.2.3 Identifier Case Sensitivity

MySQL에서 데이터베이스는 data 디렉터리 내의 디렉터리에 해당합니다. 각 데이터베이스 내의 각 테이블은 데이터베이스 디렉터리 내의 하나 이상의 파일(사용 중인 스토리지 엔진에 따라 하나 이상)에 해당합니다. 트리거도 파일에 해당합니다. 따라서 기본 운영 체제의 대소문자 구분 여부가 데이터베이스, 테이블, 트리거 이름의 대소문자 구분에 영향을 미칩니다. 이는 이러한 이름이 Windows에서는 대소문자를 구분하지 않지만, 대부분의 Unix 계열에서는 대소문자를 구분한다는 의미입니다. 주목할 만한 예외는 macOS로, Unix 기반이지만 기본 파일 시스템 타입(HFS+)이 대소문자를 구분하지 않습니다. 그러나 macOS는 Unix와 마찬가지로 대소문자를 구분하는 UFS 볼륨도 지원합니다. Section 1.7.1, “MySQL Extensions to Standard SQL”을 참조하십시오. 이 절의 뒷부분에서 설명하듯이, lower_case_table_names 시스템 변수도 서버가 식별자 대소문자 구분을 처리하는 방식에 영향을 줍니다.

참고

일부 플랫폼에서 데이터베이스, 테이블, 트리거 이름이 대소문자를 구분하지 않더라도, 같은 문장 내에서 이들 중 하나를 서로 다른 대소문자로 참조해서는 안 됩니다. 다음 문장은 하나의 테이블을 my_table과 MY_TABLE로 모두 참조하기 때문에 동작하지 않습니다:

1mysql> SELECT * FROM my_table WHERE MY_TABLE.col=1;

파티션, 서브파티션, 컬럼, 인덱스, 스토어드 루틴, 이벤트, 리소스 그룹 이름과 컬럼 별칭은 모든 플랫폼에서 대소문자를 구분하지 않습니다.

그러나 로그파일 그룹 이름은 대소문자를 구분합니다. 이는 표준 SQL과 다릅니다.

기본적으로 테이블 별칭은 Unix에서는 대소문자를 구분하지만, Windows나 macOS에서는 그렇지 않습니다. 다음 문장은 별칭을 a와 A로 모두 참조하므로 Unix에서는 동작하지 않습니다:

1mysql> SELECT col_name FROM tbl_name AS a
2       WHERE a.col_name = 1 OR A.col_name = 2;

그러나 동일한 문장은 Windows에서는 허용됩니다. 이러한 차이로 인한 문제를 피하기 위해, 데이터베이스와 테이블을 항상 소문자 이름으로 생성하고 참조하는 것과 같은 일관된 규칙을 채택하는 것이 가장 좋습니다. 이 규칙은 최대한의 이식성과 사용 편의성을 위해 권장됩니다.

테이블과 데이터베이스 이름이 디스크에 저장되고 MySQL에서 사용되는 방식은 lower_case_table_names 시스템 변수의 영향을 받습니다. lower_case_table_names는 다음 표에 표시된 값을 가질 수 있습니다. 이 변수는 트리거 식별자의 대소문자 구분에는 영향을 주지 않습니다. Unix에서 lower_case_table_names의 기본값은 0입니다. Windows에서 기본값은 1입니다. macOS에서 기본값은 2입니다.

lower_case_table_names는 서버 초기화 시에만 설정할 수 있습니다. 서버가 초기화된 후에는 lower_case_table_names 설정을 변경하는 것이 금지됩니다.

Value	Meaning
0	테이블과 데이터베이스 이름은 CREATE TABLE 또는 CREATE DATABASE 문장에 지정된 대소문자를 사용하여 디스크에 저장됩니다. 이름 비교는 대소문자를 구분합니다. 파일 이름의 대소문자를 구분하지 않는 시스템(예: Windows나 macOS)에서 MySQL을 실행 중이라면 이 변수를 0으로 설정해서는 안 됩니다. 대소문자를 구분하지 않는 파일 시스템에서 --lower-case-table-names=0를 사용해 이 변수를 0으로 강제 설정하고, 서로 다른 대소문자를 사용해 MyISAM 테이블 이름에 접근하면 인덱스 손상이 발생할 수 있습니다.
1	테이블 이름은 디스크에 소문자로 저장되고 이름 비교는 대소문자를 구분하지 않습니다. MySQL은 저장과 조회 시 모든 테이블 이름을 소문자로 변환합니다. 이 동작은 데이터베이스 이름과 테이블 별칭에도 적용됩니다.
2	테이블과 데이터베이스 이름은 CREATE TABLE 또는 CREATE DATABASE 문장에 지정된 대소문자를 사용하여 디스크에 저장되지만, MySQL은 조회 시 이들을 소문자로 변환합니다. 이름 비교는 대소문자를 구분하지 않습니다. 이는 대소문자를 구분하지 않는 파일 시스템에서만 동작합니다! InnoDB 테이블 이름과 뷰 이름은 lower_case_table_names=1인 경우와 마찬가지로 소문자로 저장됩니다.

하나의 플랫폼에서만 MySQL을 사용한다면 보통 기본값 이외의 lower_case_table_names 설정을 사용할 필요는 없습니다. 그러나 파일 시스템의 대소문자 구분이 다른 플랫폼 간에 테이블을 전송하고자 할 경우에는 문제가 발생할 수 있습니다. 예를 들어, Unix에서는 my_table과 MY_TABLE이라는 서로 다른 두 테이블을 가질 수 있지만, Windows에서는 이 두 이름이 동일한 것으로 간주됩니다. 데이터베이스나 테이블 이름의 대소문자로 인한 데이터 전송 문제를 피하려면 다음 두 가지 선택지가 있습니다:

• 모든 시스템에서 lower_case_table_names=1을 사용합니다. 이 접근 방식의 주요 단점은 SHOW TABLES 또는 SHOW DATABASES를 사용할 때, 이름이 원래의 대소문자로 보이지 않는다는 점입니다.

• Unix에서는 lower_case_table_names=0을, Windows에서는 lower_case_table_names=2를 사용합니다. 이렇게 하면 데이터베이스와 테이블 이름의 대소문자가 보존됩니다. 단점은 Windows에서 문장이 항상 올바른 대소문자로 데이터베이스와 테이블 이름을 참조하도록 보장해야 한다는 점입니다. 이러한 문장을 대소문자가 중요한 Unix로 전송하면, 대소문자가 올바르지 않은 경우 동작하지 않습니다.

Exception: InnoDB 테이블을 사용하고 있고 이러한 데이터 전송 문제를 피하려는 경우, 모든 플랫폼에서 lower_case_table_names=1을 사용하여 이름이 소문자로 변환되도록 해야 합니다.

오브젝트 이름의 대문자 형태가 바이너리 콜레이션 기준으로 동일한 경우, 이들은 중복으로 간주될 수 있습니다. 이는 커서, 컨디션, 프로시저, 함수, 세이브포인트, 스토어드 루틴 파라미터, 스토어드 프로그램 로컬 변수, 플러그인 이름에 대해 참입니다. 그러나 컬럼, 제약, 데이터베이스, 파티션, PREPARE로 준비된 문장, 테이블, 트리거, 사용자, 사용자 정의 변수 이름에 대해서는 참이 아닙니다.

파일 시스템의 대소문자 구분은 INFORMATION_SCHEMA 테이블의 문자열 컬럼 검색에 영향을 줄 수 있습니다. 자세한 내용은 Section 12.8.7, “Using Collation in INFORMATION_SCHEMA Searches”를 참조하십시오.