DBMS 2

DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!

언어 구조 (Language Structure)

DBMS 2
MySQL 가이드
언어 구조 (Language Structure)
언어 구조 (Language Structure)
작성자
admin
작성일
2021-02-19 10:59
조회
885

리터럴 값 (Literal Values)

스트링 (Strings)
숫자 (Numbers)
16진수 값 (Hexadecimal Values)
불리안 값 (Boolean Values)
비트-필드 값 (Bit-Field Values)
NULL 값

이 섹션에서는 MySQL에서 리터럴 값을 작성하는 방법을 설명하기로 한다. 리터럴 값에는 스트링, 숫자, 16진수 값, 불리안 값, 그리고 NULL이 포함된다. 이 섹션에서는 또한 여러분이 이러한 기본적인 타입을 MySQL에서 다룰 때 구동할 수 있는 다양한 의미 등에 대해서도 다룰 것이다.


스트링 (Strings)

스트링은 단일 인용 부호 (“'”) 또는 이중 인용 부호 (“"”)로 둘러 쌓인 문자 또는 바이트 시퀀스를 의미한다. 예를 들면:



'a string'
"another string"


만일 ANSI_QUOTES SQL 모드가 활성화 되어 있다면, 스트링 리터럴은 단일 인용 부호만을 사용할 수 있는데, 그 이유는 이중 부호를 사용하게 되면 이것을 아이덴티파이어 (identifier)로 해석하기 때문이다.

바이너리 스트링은 어떠한 문자 셋 또는 콜레션 (collation)도 가지고 있지 않는 바이트 스트링을 의미한다. 반면에, 비-바이너리 스트링 (non-binary string)은 문자 셋과 콜레션을 가지고 있는 문자 스트링을 의미한다. 두 가지 형태의 스트링 모두, 스트링 유닛 (unit) 숫자 값을 기반으로 비교 연산을 실행한다. 바이너리 스트링은 바이트가 유닛이 되고, 비-바이너리 스트링은 문자를 유닛으로 사용 하는데 간혹 멀티-바이트 문자를 사용하는 경우도 있다. 문자 값 순서는 스트링 콜레션의 함수가 된다.

스트링 리터럴은 옵션으로 문자 셋 인트로듀서 (introducer) 및 COLLATE 구문을 가질 수도 있다:



[_charset_name]'string' [COLLATE collation_name]
예제:

SELECT _latin1'string';
SELECT _latin1'string' COLLATE latin1_danish_ci


스트링 안에 있는 어떤 시퀀스는 특별한 의미를 갖기도 한다. 이러한 시퀀스들은 각각 이스케이프 문자로 알려져 있는 백 슬레시 (“\”)로 시작이 된다. MySQL은 아래의 이스케이프 시퀀스를 인식한다: :


\0 An ASCII 0 (NUL) character.
\' A single quote (‘'’) character.
\" A double quote (‘"’) character.
\b A backspace character.
\n A newline (linefeed) character.
\r A carriage return character.
\t A tab character.
\Z ASCII 26 (Control-Z). See note following the table.
\\ A backslash (‘\’) character.
\% A ‘%’ character. See note following the table.
\_ A ‘_’ character. See note following the table.

다른 모든 이스케이프 시퀀스에 대해서는 백 슬레시가 무시된다. 즉, 이스케이프 문자는 이스케이프가 아닌 것처럼 해석이 된다. 예를 들면, ‘\x’ 는 단지 ‘x’로 해석된다.

이러한 시퀀스들은 대소 문자를 구분한다. 예를 들면, ‘\b’는 백 스페이스로 해석되지만, ‘\B’는 ‘B’로 해석된다.

ASCII 26 문자는 윈도우에서 END-OF-FILE을 나타내는 ASCII 26 문제를 해결할 수 있도록 ‘\Z’로 해석된다. 여러분이 mysql db_name < file_name를 시도할 경우에 파일 안에 있는 ASCII 26은 문제를 발생 시킨다.

‘\%’ 와 ‘\_’ 시퀀스는 패턴-매칭 문장에서는 ‘%’ 와 ‘_’의 리터럴 인스턴스를 검색하기 위한 용도로 사용된다. 만일 ‘\%’ 또는 ‘\_’를 비-패턴-매칭 문장에서 사용한다면, 이것들은 스트링 ‘\%’ 와 ‘\_’로 해석되고, ‘%’ 와 ‘_’로는 해석되지 않게 된다.

스트링 안에 인용 부호를 포함 시키는 방법은 여러 가지가 있다:


  • 단일 인용 부호 안에 있는 스트링 내부의 ‘'’는 ‘''’ 형태로 작성될 수도 있다.
  • 이중 인용 부호 안에 있는 스트링 내부의 ‘"’는 ‘""’ 형태로 작성될 수도 있다.
  • 이스케이프 문자 (‘\’) 앞에는 인용 문자를 앞세운다.
  • 이중 인용 부호 안에 있는 스트링 내부의 ‘'’는 특별히 다룰 필요가 없으며 이중 처리 또는 이스케이프 문자를 달 필요가 없다. 같은 방식으로, 단일 인용 부호 안에 있는 스트링 내부의 ‘"’ 도 특별히 다룰 필요가 없다.

아래의 SELECT 명령문은 인용 부호 및 이스케이핑을 어떻게 사용하는지를 보여 주는 예문이다:



mysql> SELECT 'hello', '"hello"', '""hello""', 'hel''lo', '\'hello';
+-------+---------+-----------+--------+--------+
| hello | "hello" | ""hello"" | hel'lo | 'hello |
+-------+---------+-----------+--------+--------+

mysql> SELECT "hello", "'hello'", "''hello''", "hel""lo", "\"hello";
+-------+---------+-----------+--------+--------+
| hello | 'hello' | ''hello'' | hel"lo | "hello |
+-------+---------+-----------+--------+--------+

mysql> SELECT 'This\nIs\nFour\nLines';
+--------------------+
| This
Is
Four
Lines |
+--------------------+

mysql> SELECT 'disappearing\ backslash';
+------------------------+
| disappearing backslash |
+------------------------+


만일 스트링 컬럼 (BLOB 컬럼과 같은 것) 안에 바이너리 데이터를 삽입하고자 한다면, 아래의 문자는 반드시 이스케이프 시퀀스를 사용해서 표시되어야 한다:


NUL NUL byte (ASCII 0). Represent this character by ‘\0’ (a backslash followed by an ASCII ‘0’ character).
\ Backslash (ASCII 92). Represent this character by ‘\\’.
2 Master_Log_File
' Single quote (ASCII 39). Represent this character by ‘\'’.
" Double quote (ASCII 34). Represent this character by ‘\"’.

어플리케이션 프로그램을 작성하는 경우에는, 이러한 특수 문자를 가지고 있는 스트링은 MySQL 서버에 보내지는 SQL 명령문에서 이 스트링을 사용하기 전에 반드시 올바르게 이스케이프가 되어야 한다. 이것은 두 가지 방식으로 처리할 수가 있다:


  • 특수 문자를 이스케이프 시키는 함수를 사용해서 스트링을 처리한다. C 프로그램에서는, mysql_real_escape_string() C API 함수를 사용해서 문자를 이스케이프 시킨다. Perl DBI 인터페이스는 quote 방식을 사용해서 특수 문자를 적당한 이스케이프 문자로 변환시킨다. 다른 언어 인터 페이스에서도 이와 유사한 방식이 있다.
  • 특수 문자를 확실하게 이스케이프 시키기 위한 다른 방안으로, 많은 수의 MySQL API가 특수 마커 (marker)를 명령문 스트링에 삽입할 수 있도록 해 주는 플레이스홀더 (placeholder)를 제공하고 있으며, 이것은 입력된 명령문을 데이터 값을 이것들과 묶어 버린다. 이와 같은 경우, API는 이 값에서 이스케이프 특수 문자를 조심스럽게 처리한다.
숫자 (Numbers)

정수는 숫자 (digit)의 시퀀스 형태로 표현된다. 부동 소수점은 10진법 구분자 (separater)로 ‘.’을 사용한다. 두 가지 숫자 모두 음수 또는 양수를 표시하기 위해서 ‘-’ 또는 ‘+’를 각각 앞에 사용할 수도 있다.

유효한 정수 값의 예를 보면:



1221
0
-32


유효한 부동 소수점 숫자의 예를 보면:



294.42
-32032.6809e+10
148.00


정수를 소수점 문장 안에서 사용할 수도 있다; 이렇게 하면, 정수는 소수점 숫자와 동일하게 취급된다.


16진수 값 (Hexadecimal Values)

MySQL은 16 진수 값을 지원한다. 숫자 문장안에서 16진수 값은 정수처럼 동작을 한다 (64-비트 표현식). 반면에, 스트링 문자에서는 바이너리 스트링처럼 동작을 하며, 각각의 16진수 쌍은 하나의 문자로 변환된다:



mysql> SELECT x'4D7953514C';
-> 'MySQL'
mysql> SELECT 0xa+0;
-> 10
mysql> SELECT 0x5061756c;
-> 'Paul'


16진수 값의 디폴트 타입은 스트링이다. 이 값을 확실하게 숫자로 처리하고 싶다면, CAST(... AS UNSIGNED)를 사용하도록 한다:



mysql> SELECT 0x41, CAST(0x41 AS UNSIGNED);
-> 'A', 65


x'hexstring' 신텍스는 표준 SQL를 기반으로 한다. 0x 신텍스는 ODBC에 기반을 둔다. BLOB 컬럼 값을 지원하기 위해서 ODBC가 16진수 스트링을 사용하는 경우도 종종 있다.

HEX() 함수를 사용하면 스트링 또는 숫자를 16진수 포맷 스트링으로 변환 시킬 수가 있다:



mysql> SELECT HEX('cat');
-> '636174'
mysql> SELECT 0x636174;
-> 'cat'


불리안 값 (Boolean Values)

상수 (constants) TRUE 와 FALSE는 각각 1 과 0으로 해석된다. 상수 이름은 대소 문자 구분을 하지 않는다.



mysql> SELECT TRUE, true, FALSE, false;
-> 1, 1, 0, 0


비트-필드 값 (Bit-Field Values)

MySQL 5.0.3 이후에는, 비트-필드 (bit-field) 값을 b'value' 표기법을 사용해서 작성할 수 있게 되었다. value 는 여러 개의 0 과 1을 사용해서 작성된 바이너리 값이다.

비트-필드 표기법 (Bit-field notation)은 BIT 컬럼에 값을 지정할 때 편리하게 사용할 수 있는 방법이다:



mysql> CREATE TABLE t (b BIT(8));
mysql> INSERT INTO t SET b = b'11111111';
mysql> INSERT INTO t SET b = b'1010';
+------+----------+----------+----------+
| b+0 | BIN(b+0) | OCT(b+0) | HEX(b+0) |
+------+----------+----------+----------+
| 255 | 11111111 | 377 | FF |
| 10 | 1010 | 12 | A |


NULL 값

NULL 값은 “데이터가 없음 (no data)”을 의미한다. NULL은 대소 문자 구분을 하지 않는다.

NULL 값은 숫자 타입용 0 또는 스트링 타입용 빈 스트링 (empty string)과는 다른 것임을 알아야 한다.

LOAD DATA INFILE 또는 SELECT ... INTO OUTFILE을 사용해서 실행되는 텍스트 파일 임포트 또는 익스포트의 경우, NULL은 \N 시퀀스를 가지고 표시가 된다.


데이터 베이스, 테이블, 인덱스, 컬럼, 그리고 별칭 (Alias Names)

아이덴티파이어 수식어 (Identifier Qualifiers)
아이덴티파이어 대소 문자 구분 (Identifier Case Sensitivity)

데이터 베이스, 테이블, 인덱스, 컬럼 그리고 별칭은 아이덴티파이어이다. 이 섹션에서는 MySQL에서 사용할 수 있는 아이덴티파이어에 대해서 설명하기로 한다.

아래의 테이블에서는 각각의 아이덴티파이어 타입이 가질 수 있는 최대 크기를 보여 준다.


Identifier Maximum Length
Database 64
Table 64
Column 64
Index 64
Alias 255

아이덴티파이어에 나타날 수 있는 문자에는 몇 가지 제약이 존재한다:


  • 어떠한 아이덴티파이어도 ASCII 0 (0x00) 또는 255 값을 사용하는 바이트를 가질 수 없다.
  • 아이덴티파이어 안에서 아이덴티파이어 인용 부호 문자를 사용하는 것은 가능하지만, 가능하면 이 방법을 사용하지 않는 것이 좋다.
  • 데이터 베이스, 테이블, 그리고 컬럼 이름은 스페이스 문자로 끝나지 말아야 한다.
  • ‘/’, ‘\’, ‘.’, 또는 디렉토리 이름으로 사용할 수 없는 문자는 데이터 베이스 이름으로 사용할 수 없다.
  • ‘/’, ‘\’, ‘.’, 또는 파일 이름으로 사용할 수 없는 문자는 테이블 이름으로 사용할 수 없다.

아이덴티파이어는 유니 코드 (UTF-8)을 사용해서 저장된다. 이것은 .frm 파일에 저장된 테이블 정의문의 아이덴티파이어 및 mysql 데이터 베이스의 그랜트 테이블에 저장된 아이덴티파이어에 적용된다. MySQL 5.0의 그랜트 테이블 (그리고 다른 테이블)에 있는 스트링 컬럼의 크기는 문자의 수로 주어진다. 이것은 (MySQL 이전 버전과는 달리), 여러분이 이러한 컬럼에 저장되는 값에 대해서 다중-바이트 문자를 사용할 수 있다는 것을 의미하는 것이다.

아이덴티파이어는 인용 부호를 사용할 수도 있고 사용하지 않을 수도 있다. 만일 아이덴티파이어가 사용 지정된 단어이거나 또는 특수 문자를 가지고 있다면, 이것을 참조할 때마다 반드시 인용 부호를 사용하도록 한다. (예외 사항: 사용할 수 있는 이름 안에 점 (period)이 붙어 있는 단어는 반드시 아이덴티파이어이기 때문에, 이것이 사용 지정 단어라고 하더라고 인용 부호를 사용할 필요는 없게 된다.) 특수 문자는 알파뉴메릭 (alphanumeric) 문자 셋 이외의 문자들을 의미한다.

아이덴티파이어 인용 문자는 백틱 (backtick) (‘`’)이다:



mysql> SELECT * FROM `select` WHERE `select`.id > 100; 

ANSI_QUOTES SQL 모든가 활성화 되어 있다면, 이중 인용 부호를 사용해서 아이덴티파이어를 처리하는 것이 가능하다:


mysql> CREATE TABLE "test" (col INT); 

ERROR 1064: You have an error in your SQL syntax. (...)

mysql> SET sql_mode='ANSI_QUOTES';

mysql> CREATE TABLE "test" (col INT);

Query OK, 0 rows affected (0.00 sec)


Note: ANSI_QUOTES 모드는 서버가 이중 인용 부호를 사용한 스트링을 아이덴티파이어로 해석하도록 만들기 때문에, 이 모드가 활성화 되어 있는 경우에는 반드시 스트링 리터럴을 단일 인용 부호로 처리해야만 한다. 이중 인용 부호를 사용해서는 처리할 수가 없다.

아이덴티파이어 인용 문자는 아이덴티파이어를 인용 부호화할 경우에 아이덴티파이어 안에 포함 시킬 수가 있다. 만일 아이덴티파이어 안에 포함 시켜야 할 문자가 아이덴티파이어 자체를 인용 부호화 하는데 사용한 것과 같을 경우에는, 이중 인용 부호를 사용하면 된다. 아래의 명령문은 c"d라는 이름의 컬럼을 가지고 있는 a`b 라는 이름의 테이블을 생성한다



mysql> CREATE TABLE `a``b` (`c"d` INT); 

M 과 N 이 정수인 경우에는 Me 또는 MeN 형태의 이름을 사용하지 말도록 한다. 예를 들면, 아이덴티파이어로 1e 또는 2e2 와 같은 형태는 피해야 하는데, 그 이유는 1e+3 와 같은 수식이 애매해질 수 있기 때문이다. 문장에 따라서, 이러한 이름은 수식 1e + 3 또는 숫자 1e+3로 해석될 수도 있다.

MD5()을 사용해서 테이블 이름을 생성할 때에는 주의를 해야 하는데, 그 이유는 이것이 위에서 설명한 것과 유사한 애매한 포맷 또는 올바르지 못한 이름을 만들기 때문이다.


아이덴티파이어 수식어 (Identifier Qualifiers)

MySQL 은 단일 아이덴티파이어 또는 여러 개의 아이덴티파이어로 구성된 이름을 허용한다. 여러 부분으로 이름을 만들 경우에는 점 (‘.’) 으로 구분을 하도록 한다. 여러 부분으로 되어 있는 이름의 첫 부분이 마지막 아이덴티파이어를 해석하는 수식어로 동작을 한다.

ySQL에서는 아래의 형태 중의 하나를 사용해서 컬럼을 참조할 수 있다:


Column Reference Meaning
col_name The column col_name from whichever table used in the statement contains a column of that name.
tbl_name.col_name The column col_name from table tbl_name of the default database.
db_name.tbl_name.col_name The column col_name from table tbl_name of the database db_name.

만일 여러 부분으로 구성된 이름 중의 일부가 인용 부호를 필요로 할 경우에는, 이름 전체 보다는 개별적으로 인용 부호화 한다. 예를 들면, `my-table`.`my-column` 형태로 하면 되며, `my-table.my-column` 형태로는 하지 않도록 한다.

명령문 안에 있는 컬럼을 참조하기 위해서는, 참조가 애매하지 않는 이상 tbl_name 또는 db_name.tbl_name 접두사를 지정할 필요가 없다. 테이블 t1 과 t2가 각각 컬럼 c를 가지고 있고, 테이블 t1 과 t2 모두를 사용하는 SELECT 명령문에서 c를 추출한다고 가정하자. 이러한 경우, c는 이 명령문 내 테이블 사이에서 유니크 (unique)하지 않기 때문에 애매 모호한 상태가 된다. 이럴 때에는 여러분이 의미하는 테이블이 어떤 것인지를 분명히 하기 위해서 t1.c 또는 t2.c 형태로 표현을 해주어야 한다. 비슷하게, db1에서 t를 추출하고 동일한 명령문에서 db2에 있는 t를 추출하기 위해서는, db1.t.col_name 과 db2.t.col_name 같은 형태로 테이블에서 컬럼을 참조해야 한다.

사용 가능한 이름에서 점 (period) 다음에 나오는 단어는 반드시 아이덴티파이어 이어야 하기 때문에, 이것이 사용 지정된 단어일지라도 인용 부호화 할 필요는 없다.

신텍스 .tbl_name는 디폴트 데이터 베이스에 있는 테이블 tbl_name을 의미한다. 몇몇 ODBC 프로그램이 테이블 이름을 ‘.’ 문자로 시작하기 때문에 ODBC에서는 이 신텍스를 인식할 수가 있다.


아이덴티파이어 대소 문자 구분 (Identifier Case Sensitivity)

MySQL에서는 데이터 베이스가 데이터 디렉토리에 있는 디렉토리와 대응이 된다. 하나의 데이터 베이스에 들어 있는 각각의 테이블은 데이터 베이스 디렉토리에 들어 있는 파일과 최소한 한 개가 대응이 된다 (또한, 스토리지 엔진에 따라서 여러 개와 연결될 수도 있음). 결론적으로, 사용하는OS 환경이 대소 문자를 구분하는지에 따라서 데이터 베이스와 테이블 이름에 대한 대소 문자 구분이 이루어지는 것이다. 즉, 대부분의 유닉스에서는 데이터 베이스와 테이블 이름이 대소 문자를 구분하며, 윈도우에서는 그렇지 않다는 것을 의미하는 것이다. 하지만 Mac OS X의 경우는 예외인데, 이 OS는 유닉스 기반이기는 하지만 이것이 사용하는 디폴트 파일 시스템 (HFS+)은 대소 문자를 구분하지 않는다. 하지만, Mac OS X 역시 UFS를 지원하며, UFS는 대소 문자를 구분한다는 점을 알아두도록 한다. lower_case_table_names 시스템 변수 역시 서버가 아이덴티파이어의 대소 문자를 처리하는 동작에 영향을 준다.

Note: 비록 데이터 베이스 및 테이블 이름이 어떤 플랫폼에서는 대소 문자를 구분하지 않는다 하더라도, 동일한 명령문 내에서는 데이터 베이스 및 테이블 이름을 대소 문자를 혼용해서 지정하지 않도록 한다. 아래의 명령문은 하나의 동일 테이블을 my_table 및 MY_TABLE로 참조하기 때문에 동작을 하지 않게 된다:



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

컬럼, 인덱스, 스토어드 루틴, 그리고 트리거의 이름은 모든 플랫폼에서 대소 문자를 구분하지 않으며, 컬럼 별칭도 마찬가지다.

유닉스에서는 테이블 별칭의 대소 문자를 디폴트로 구분하지만, 윈도우 또는 Mac OS X에서는 그렇지 않다. 아래의 명령문은 유닉스에서는 동작을 하지 않는데, 그 이유는 이것이 a 및 A 형태로 별칭을 참조하기 때문이다:



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


하지만, 윈도우에서는 위 명령문을 동작 시킬 수가 있다. 이와 같은 차이점으로 인한 문제를 해결하기 위해서는, 데이터 베이스와 테이블을 생성하고 참조할 경우에는 항상 소문자 이름을 사용하도록 하는 것과 같이 상수 변환을 적용하는 것이 최선의 방법이다. 이 방식이 이식성 (portability)을 최대한 보장해 주고 사용을 용이하게 해 주기 때문에 권장하고 있다.

MySQL에서 테이블 및 데이터 베이스를 디스크에 저장해서 사용하는 방법은 lower_case_table_names 시스템 변수로 제어할 수 있으며, mysqld를 시작하는 시점에 이 변수를 설정할 수 있다. lower_case_table_names는 아래의 테이블에서 값을 가져온다. 유닉스의 경우, lower_case_table_names의 디폴트 값은0 이다. 윈도우의 경우에는 1 이 되며, Mac OS X는 디폴트가 2가 된다.


Value Meaning
0 Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or CREATE DATABASE statement. Name comparisons are case sensitive. Note that if you force this variable to 0 with --lower-case-table-names=0 on a case-insensitive filesystem and access MyISAM tablenames using different lettercases, index corruption may result.
1 Table names are stored in lowercase on disk and name comparisons are not case sensitive. MySQL converts all table names to lowercase on storage and lookup. This behavior also applies to database names and table aliases.
2 Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or CREATE DATABASE statement, but MySQL converts them to lowercase on lookup. Name comparisons are not case sensitive. Note: This works only on filesystems that are not case sensitive! InnoDB table names are stored in lowercase, as for lower_case_table_names=1.

하나의 플랫폼 상에서만 MySQL을 사용한다면, lower_case_table_names 변수를 변경 시킬 필요는 없다. 하지만, 파일 시스템이 대소 문자를 구분하는 플랫폼 간에 테이블을 전달하고자 하는 경우에는 어려움을 직면할 수도 있게 된다. 예를 들면, 유닉스 상에서는 이름이 my_table 과 MY_TABLE인 두 개의 테이블을 가질 수는 있으나, 윈도우에서는 이 두 개의 테이블이 동일한 것으로 간주된다. 문자 크기에 민감한 테이블과 데이터 베이스 이름 전송 문제를 해결하기 위해서는, 아래의 두 가지 옵션을 사용해야 한다:


  • 모든 시스템에서 lower_case_table_names=1 로 설정을 한다. 이렇게 할 경우의 가장 큰 단점은, SHOW TABLES 또는 SHOW DATABASES를 사용할 경우에, 이것들의 원래 문자 크기로 된 이름을 볼 수 없다는 점이다
  • 유닉스에서는 lower_case_table_names=0로 설정하고, 윈도우에서는 lower_case_table_names=2로 설정한다. 이렇게 하면, 데이터 베이스 및 테이블 이름의 원래 문자 크기가 보존된다. 이렇게 할 경우의 단점으로는, 여러분이 사용하는 명령문이 항상 윈도우에서 정확한 문자 크기를 사용해서 데이터 베이스 및 테이블 이름을 참조하는 것을확인을 해야 한다는 것이다. 만일 명령문을 문자 크기에 민감한 유닉스로 전송할 경우에는, 문자 크기가 정확하기 않는 명령문은 동작을 하지 않게 된다.
    Exception: 만일 InnoDB 테이블을 사용한다면, 모든 플랫폼 상에서 lower_case_table_names를 1로 설정해서 이름을 강제로 소문자로 변환하도록 해야 한다.

만일 유닉스에서 lower_case_table_names 시스템 변수를 1로 설정하고자 한다면, 우선 구형 데이터 베이스 및 테이블 이름을 소문자로 변경한 후에 mysqld을 새로운 변수 값으로 재 시작해야 한다.


사용자 정의 변수

여러분은 사용자 정의 변수에 값을 저장한 후에 나중에 그 값을 참조할 수 있다. 이를 통해 하나의 명령문에 있는 값을 다른 명령문으로 전달하는 것이 가능하다. 사용자 정의 변수는 특정 커넥션에 국한되어 있다. 다시 말해, 한 클라이언트에서 정의된 사용자 변수는 다른 클라이언트에서는 보이지 않으며 사용할 수 없다. 해당 커넥션에서 정의된 모든 변수는 클라이언트가 종료되면 자동으로 해제된다.

변수 명은 var_name 이라고 쓰는 반면, 사용자 변수는 @var_name 이라고 쓴다. 사용자 변수 이름은 알파벳, 숫자, ‘.’, ‘_’, 그리고 ‘$’을 사용할 수 있다. 기본 문자 집합은 latin1이다 (cp 1252 서 유럽어). 이것은 mysqld 에서 --default-character-set옵션을 사용해서 바꿀 수 있다. 문자열 또는 아이덴티파이어에 인용 부호를 사용한다면 다른 문자도 사용자 정의 변수 이름으로 사용할 수 있다 (예를 들어, @'my-var', @"my-var", 또는 @`my-var`).

Note: MySQL 5.0이전 버전에서는 사용자 변수 명에 대소문자를 구분 하였지만, MySQL 5.0 이후부터는 대소문자를 가리지 않는다.

사용자 정의 변수는 SET문을 이용해서 설정할 수 있다:



SET @var_name = expr [, @var_name = expr] ... 

SET문에서는 할당 연산자로 = 또는 := 모두 사용될 수 있다. 각 변수에 할당되는 expr은 정수, 실수, 문자열 또는 NULL값을 계산한다. SET 문이 아닌 다른 것으로도 사용자 정의 변수 값을 할당할 수 있다. 이 경우에는, 할당 연산자는 = 가 아닌 := 가 되어야 한다. 비-SET 명령문에서는 =가 비교 연산자로 취급된다:



mysql> SET @t1=0, @t2=0, @t3=0; 

mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;

+----------------------+------+------+------+

| @t1:=(@t2:=1)+@t3:=4 | @t1 | @t2 | @t3 |

+----------------------+------+------+------+

| 5 | 5 | 1 | 4 |

+----------------------+------+------+------+




사용자 변수는 수식을 사용할 수 있는 문장에서도 사용될 수 있다. 하지만 SELECT 구문의 LIMIT 명령문, 또는 LOAD DATA 구문의 IGNORE N LINES 구문과 같이 문자만 사용해야 하는 곳에서는 사용할 수가 없다.

사용자 변수에 스트링 값을 할당하면, 변수는 스트링과 동일한 문자 셋과 콜레션을 갖는다. 사용자 변수의 코시빌리티 (coercibility)는 MySQL 5.0.3에서는 암시적이다 (implicit).

Note: SELECT 구문에서는, 각 수식은 클라이언트에 보내졌을 때에만 계산된다. 즉, HAVING, GROUP BY, 또는 ORDER BY 절에서는SELECT 리스트에 설정된 변수를 가지고 있는 수식을 참조할 수 없다는 것이다. 예를 들어, 다음 구문은 예상한 대로 동작하지 않는다:



mysql> SELECT (@aa:=id) AS a, (@aa+3) AS b FROM tbl_name HAVING b=5; 

HAVING 절에 쓰인 b는 @aa를 사용하는 SELECT 목록의 수식용 별칭을 참조한다. 이것은 예상한 대로 동작하지 않는다: @aa가 현재 열이 아닌 이전 선택 열로부터 id 값을 가지기 때문이다.

일반적인 규칙은, 사용자 변수를 한 구문 안에서 정의하면 같은 구문의 다른 부분에서 절대 사용하지 않는 것이다. 여러분은 예상한 결과를 얻을 수도 있겠지만, 반드시 보장되지는 않는다.

동일 명령문에서 변수를 정의하고 사용하는 데에 따른 또 다른 이슈 사항은, 변수의 디폴트 결과 타입이 명령문이 시작되는 시점에서의 변수 타입에 기반한다는 것이다. 다음 예제가 이것을 설명한다:



mysql> SET @a='test'; 

mysql> SELECT @a,(@a:=20) FROM tbl_name;


위의 SELECT 명령문의 경우에는, MySQL은 두 번째 열에 대해서는 @a가 숫자로 설정되었더라도, 첫 번째 컬럼은 스트링이고 @a에 대한 모든 접근을 스트링으로 변환한다고 클라이언트에 알려준다. SELECT 명령문을 실행하고 나면, 다음 구문에 대해서는 @a가 숫자로 인식된다.

이런 동작으로 인한 문제를 피하기 위해서는, 한 구문 안에 같은 변수를 동시에 설정하고 사용하지 않거나, 변수를 사용하기 전에 0, 0.0, 혹은 ‘’로 정의해야 한다.

초기화되지 않은 변수를 참조하는 경우, 그 변수는 NULL값을 갖는 스트링이 된다.


코멘트 신텍스

MySQL 서버는 세 가지 형태의 코멘트 스타일을 지원한다:


  • ‘#’문자를 사용.
  • ‘-- ’ 시퀀스를 사용한 라인. MySQL에서는, ‘-- ’ (double-dash) 코멘트 스타일은 최소한 한 개의 화이트스페이스 (whitespace) 또는 제어 문자 (control character) (스페이스, 탭, 뉴라인(newline) 등등)가 두 번째 대쉬 (the second dash) 다음에 오도록 하고 있다. 이것은 표준 SQL 코멘트 신텍스와 차이가 있는 점이다.
  • C 프로그래밍에서와 같이 /* 시퀀스로 시작해서 */ 시퀀스로 끝나는 라인. 이 신텍스는 코멘트가 시작되는 라인이 끝나는 라인과 같을 필요가 없기 때문에 여러 줄의 코멘트를 작성할 수 있도록 해 준다.

아래의 예문은 위의 세 가지 형태의 코멘트를 보여 주고 있다:



mysql> SELECT 1+1;     # This comment continues to the end of line 

mysql> SELECT 1+1; -- This comment continues to the end of line

mysql> SELECT 1 /* this is an in-line comment */ + 1;

mysql> SELECT 1+

/*

this is a

multiple-line comment

*/

1;




MySQL 서버는 C-스타일의 코멘트 중의 몇몇 변형 스타일을 지원한다. 이러한 것들은 아래의 형태를 사용해서 MySQL 확장 형태에 포함되는 코드를 작성할 수가 있다:



/*! MySQL-specific code */ 

위와 같은 경우, MySQL 서버는 코멘트에 포함되어 있는 코드를 다른 SQL 명령문 형태로 분석해서 실행을 하지만, 다른 SQL 서버는 이것을 무시한다. 예를 들면, MySQL 서버는 아래의 명령문에 있는 STRAIGHT_JOIN 키워드를 인식하지만, 다른 SQL 서버는 인식하지 못한다:



SELECT /*! STRAIGHT_JOIN */ col1 FROM table1,table2 WHERE ... 

만일 여러분이 ‘!’ 문자 다음에 버전 정보를 추가한다면, 이 신텍스는 이렇게 지정된 MySQL 버전과 같거나 보다 늦게 출시된 서버에서만 실행이 된다. 아래의 코멘트에 있는 TEMPORARY 키워드는 MySQL 3.23.02 또는 그 이상 버전의 서버에서만 구동을 한다:



CREATE /*!32302 TEMPORARY */ TABLE t (a INT); 

위에서 설명한 코멘트는 mysqld 서버가 SQL명령문을 분석하는 방식을 설명하는 것이다. 또한, mysql 클라이언트 프로그램은 서버에 명령문을 보내기 전에 몇 가지 파싱 동작을 실행하기도 한다. (이러한 동작은 다중 명령문 입력 라인 안에 있는 명령문의 범위를 판단하기 위해 실행된다.)


MySQL 에서 사용 지정된 단어 다루기

SELECT와 같이 사용이 지정된 단어, TIMESTAMP 또는 GROUP와 같은 빌트-인 (built-in) MySQL 데이터 타입 또는 함수 이름을 테이블 또는 컬럼 이름과 같은 아이덴티파이어로 사용하고자 시도를 할 때에는 문제가 발생한다.

만일 아이덴티파이어가 사용 지정 단어라면, 여러분은 반드시 이것을 인용 부호화 해야 한다. 예외 사항: 수식 이름에서 점을 가지고 있는 단어는 반드시 아이덴티파이어이기 때문에, 이 단어가 사용 지정 단어일 지라도, 인용 부호를 사용할 필요는 없다.

함수 이름을 아이덴티파이어로 사용하는 것은 가능하다. 예를 들면, ABS를 컬럼 이름으로 사용하는 것은 가능하다. 하지만, 디폴트로는, 함수를 호출 할 때에는 함수 이름과 ‘(’ 문자 사이에 어떠한 화이트스페이스 (whitespace)도 사용할 수가 없다. 이러한 요구 사항은 컬럼 이름에 대한 참조와 함수 호출을 구분하기 위해 필요한 것이다.

이러한 특성으로 인해 몇몇 문장 안에서 스페이스를 생략하면 이것을 함수 이름으로 해석하는 경우가 발생한다. 예를 들면, 아래의 명령문은 사용 가능하다:



mysql> CREATE TABLE abs (val INT); 

하지만 abs 다음에 스페이스를 생략하게 되면, 이 신텍스는 에러를 발생시키는데, 그 이유는 이 명령문이 ABS() 함수를 호출하는 것으로 생각되기 때문이다:



mysql> CREATE TABLE abs(val INT); 

ERROR 1064 (42000) at line 2: You have an error in your SQL

syntax ... near 'abs(val INT)'


만일 IGNORE_SPACE SQL 모드가 활성화 되어 있다면, 서버는 함수 호출에서 함수 이름과 ‘(’ 문자 사이에 화이트스페이스를 가지는 것을 허용한다. 이렇게 하면 함수 이름은 사용 지정 단어처럼 취급된다. 결론적으로, 함수 이름과 동일한 아이덴티파이어는 반드시 인용 부호화 되어야 한다.

아래의 테이블에 있는 단어들은 MySQL 5.0에서 명확하게 사용이 지정된 단어들이다. 여러분이 보다 상위의 버전으로 업데이트를 하고자 할 때에는 향후에 사용이 지정될 단어를 미리 알아보는 것이 좋다. 아래의 테이블에 있는 대부분의 단어들은 표준 SQL에서 컬럼 또는 테이블 이름으로 사용할 수 없는 것들이다 (GROUP와 같이).


ADD ALL ALTER
ANALYZE AND AS
ASC ASENSITIVE BEFORE
BETWEEN BIGINT BINARY
BLOB BOTH BY
CALL CASCADE CASE
CHANGE CHAR CHARACTER
CHECK COLLATE COLUMN
CONDITION CONNECTION CONSTRAINT
CONTINUE CONVERT CREATE
CROSS CURRENT_DATE CURRENT_TIME
CURRENT_TIMESTAMP CURRENT_USER CURSOR
DATABASE DATABASES DAY_HOUR
DAY_MICROSECOND DAY_MINUTE DAY_SECOND
DEC DECIMAL DECLARE
DEFAULT DELAYED DELETE
DESC DESCRIBE DETERMINISTIC
DISTINCT DISTINCTROW DIV
DOUBLE DROP DUAL
EACH ELSE ELSEIF
ENCLOSED ESCAPED EXISTS
EXIT EXPLAIN FALSE
FETCH FLOAT FLOAT4
FLOAT8 FOR FORCE
FOREIGN FROM FULLTEXT
GRANT GROUP HAVING
HIGH_PRIORITY HOUR_MICROSECOND HOUR_MINUTE
HOUR_SECOND IF IGNORE
IN INDEX INFILE
INNER INOUT INSENSITIVE
INSERT INT INT1
INT2 INT3 INT4
INT8 INTEGER INTERVAL
INTO IS ITERATE
JOIN KEY KEYS
KILL LEADING LEAVE
LEFT LIKE LIMIT
LINES LOAD LOCALTIME
LOCALTIMESTAMP LOCK LONG
LONGBLOB LONGTEXT LOOP
LOW_PRIORITY MATCH MEDIUMBLOB
MEDIUMINT MEDIUMTEXT MIDDLEINT
MINUTE_MICROSECOND MINUTE_SECOND MOD
MODIFIES NATURAL NOT
NO_WRITE_TO_BINLOG NULL NUMERIC
ON OPTIMIZE OPTION
OPTIONALLY OR ORDER
OUT OUTER OUTFILE
PRECISION PRIMARY PROCEDURE
PURGE RAID0 READ
READS REAL REFERENCES
REGEXP RELEASE RENAME
REPEAT REPLACE REQUIRE
RESTRICT RETURN REVOKE
RIGHT RLIKE SCHEMA
SCHEMAS SECOND_MICROSECOND SELECT
SENSITIVE SEPARATOR SET
SHOW SMALLINT SONAME
SPATIAL SPECIFIC SQL
SQLEXCEPTION SQLSTATE SQLWARNING
SQL_BIG_RESULT SQL_CALC_FOUND_ROWS SQL_SMALL_RESULT
SSL STARTING STRAIGHT_JOIN
TABLE TERMINATED THEN
TINYBLOB TINYINT TINYTEXT
TO TRAILING TRIGGER
TRUE UNDO UNION
UNIQUE UNLOCK UNSIGNED
UPDATE UPGRADE USAGE
USE USING UTC_DATE
UTC_TIME UTC_TIMESTAMP VALUES
VARBINARY VARCHAR VARCHARACTER
VARYING WHEN WHERE
WHILE WITH WRITE
X509 XOR YEAR_MONTH
ZEROFILL

아래의 단어들은 MySQL 5.0에서 새롭게 사용이 지정된 단어들이다: ASENSITIVE, CALL, CONDITION, CONNECTION, CONTINUE, CURSOR, DECLARE, DETERMINISTIC, EACH, ELSEIF, EXIT, FETCH, GOTO, INOUT, INSENSITIVE, ITERATE, LABEL, LEAVE, LOOP, MODIFIES, OUT, READS, RELEASE, REPEAT, RETURN, SCHEMA, SCHEMAS, SENSITIVE, SPECIFIC, SQL, SQLEXCEPTION, SQLSTATE, SQLWARNING, TRIGGER, UNDO, UPGRADE, WHILE.

MySQL은 이전에 많은 사람들이 이미 사용을 해 오고 있는 키워드들에 대해서는 인용 부호를 사용하지 않아도 되게끔 하고 있다. 아래의 리스트는 이러한 단어들에 대한 예이다:


  • ACTION
  • BIT
  • DATE
  • ENUM
  • NO
  • TEXT
  • TIME
  • TIMESTAMP
출처 : MySQL 코리아