MySQL 학습 시리즈 3: 데이터 유형
- 黄舟원래의
- 2016-12-28 17:38:312629검색
MYSQL의 BLOB 데이터 유형
BLOB은 가변적인 양의 데이터를 저장하는 데 사용되는 바이너리 대형 개체입니다. BLOB에는 TinyBlob, Blob, MediumBlob, LongBlob의 4가지 유형이 있습니다.
이러한 유형 간의 유일한 차이점은 저장되는 파일의 최대 크기입니다.
MySQL의 4가지 BLOB 유형 유형 크기(단위: 바이트)
TinyBlob 최대 255
Blob 최대 65K
MediumBlob 최대 16M
LongBlob 최대 4G
BLOB 열은 이진 문자열(바이트 문자열)을 저장하고 TEXT 열은 이진이 아닌 문자열(문자열)을 저장합니다.
BLOB 열은 문자 집합이 없으며, 정렬 및 비교는 열 값 바이트의 숫자 값을 기준으로 이루어지며, 값은 문자 집합을 기준으로 정렬 및 비교됩니다. set
BLOB는 이진 문자열이고 TEXT는 이진이 아닌 문자열이며 둘 다 많은 양의 정보를 저장할 수 있습니다. BLOB는 주로 사진, 오디오 정보 등을 저장합니다.
TEXT는 텍스트 파일만 저장할 수 있습니다.
SQLSERVER
SQLSERVER에는 BLOB 데이터 유형이 없고 BLOB(대형 개체 데이터 유형)만 있습니다.
text,ntext,image,nvarchar(max),varchar (max) , varbinary (max) 및 xml 데이터 유형
이러한 데이터 유형의 데이터는 LOB 유형 데이터 페이지에 저장됩니다.
열 유형
11.1.1. 수치형 개요
다음은 숫자 열 유형에 대한 개요입니다. 자세한 내용은 섹션 11.2, “숫자 유형”을 참조하세요. 컬럼 저장 요구 사항은 섹션 11.5, "컬럼 유형 저장 요구 사항"을 참조하세요.
M은 최대 표시 너비를 나타냅니다. 최대 유효 표시 너비는 255입니다. 표시 너비는 섹션 11.2, "숫자 유형"에 설명된 대로 저장 크기 또는 유형에 포함된 값의 범위와 관련이 없습니다.
숫자 열에 ZEROFILL이 지정되면 MySQL은 자동으로 UNSIGNED 속성을 열에 추가합니다.
SERIAL은 BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE의 별칭입니다.
정수 열 정의에서 SERIAL DEFAULT VALUE는 NOT NULL AUTO_INCREMENT UNIQUE의 별칭입니다.
경고: 정수 값 사이에 빼기 기호를 사용하면(그 중 하나는 UNSIGNED 유형임) 결과가 부호가 없다는 점을 분명히 해야 합니다. 섹션 12.8, “캐스트 함수 및 연산자”를 참조하세요.
· BIT[(M)]
비트 필드 유형입니다. M은 1부터 64까지의 값당 비트 수를 나타냅니다. M을 생략하면 기본값은 1입니다.
·TINYINT[(M)] [UNSIGNED] [ZEROFILL]
아주 작은 정수입니다. 부호 있는 범위는 -128부터 127까지입니다. 부호 없는 범위는 0~255입니다.
· BOOL, BOOLEAN
은 TINYINT(1)의 동의어입니다. 0 값은 거짓으로 간주됩니다. 0이 아닌 값은 참으로 간주됩니다.
향후에는 표준 SQL에 따른 전체 Boolean 유형 처리가 도입될 예정입니다.
· SMALLINT[(M)] [UNSIGNED] [ZEROFILL]
작은 정수입니다. 부호 있는 범위는 -32768부터 32767까지입니다. 부호 없는 범위는 0~65535입니다.
· MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL]
중형 정수입니다. 부호 있는 범위는 -8388608부터 8388607까지입니다. 부호 없는 범위는 0~16777215입니다.
· INT[(M)] [UNSIGNED] [ZEROFILL]
보통 크기의 정수입니다. 부호 있는 범위는 -2147483648부터 2147483647까지입니다. 부호 없는 범위는 0~4294967295입니다.
· INTEGER[(M)] [UNSIGNED] [ZEROFILL]
INT의 동의어입니다.
· BIGINT[(M)] [UNSIGNED] [ZEROFILL]
큰 정수입니다. 부호 있는 범위는 -9223372036854775808부터 9223372036854775807까지입니다. 부호 없는 범위는 0~18446744073709551615입니다.
BIGINT 열에 대해 다음 사항이 명확해야 합니다.
o 모든 산술에 부호 있는 BIGINT 또는 DOUBLE 값을 사용하므로 비트 함수를 제외하고 9223372036854775807보다 큰 값은 없습니다(63 비트)를 사용해야 합니다. Signed BIG INTEGER! 이렇게 하면 BIGINT 값을 DOUBLE로 변환할 때 반올림 오류로 인해 결과의 마지막 몇 자리가 잘못될 수 있습니다.
MySQL은 다음과 같은 상황에서 BIGINT를 처리할 수 있습니다.
§ 정수를 사용하여 부호 없는 큰 값을 BIGINT 열에 저장하는 경우.
§ MIN(col_name) 또는 MAX(col_name)에서 col_name은 BIGINT 열을 나타냅니다.
§ 연산자(+, -, * 등)를 사용하고 두 피연산자가 모두 정수인 경우.
o BIGINT 열에서 엄격한 정수 값을 유지하기 위해 문자열을 사용하는 것은 항상 가능합니다. 이 경우 MySQL은 문자열을 숫자로 변환하며 그 사이에는 배정밀도 표현이 존재하지 않습니다.
o -, + 및 * 연산자는 두 피연산자가 모두 정수 값인 경우 BIGINT 알고리즘을 사용합니다. 이는 두 개의 큰 정수를 곱하는 경우(또는 정수를 반환하는 함수에서) 결과가 9223372036854775807보다 클 때 예기치 않은 결과를 얻게 된다는 것을 보여줍니다.
· FLOAT[(M,D)] [UNSIGNED] [ZEROFILL]
작은(단정밀도) 부동 소수점 수입니다. 허용되는 값은 -3.402823466E+38 ~ -1.175494351E-38, 0 및 1.175494351E-38 ~ 3.402823466E+38입니다. 이는 IEEE 표준을 기반으로 한 이론적 한계입니다. 실제 범위는 하드웨어나 운영 체제에 따라 약간 더 작을 수 있습니다.
M은 소수점 이하 자릿수, D는 소수점 이하 자릿수입니다. M과 D를 생략하면 하드웨어에서 허용하는 제한에 따라 값이 저장됩니다. 단정밀도 부동 소수점 숫자는 소수점 이하 약 7자리까지 정확합니다.
UNSIGNED를 지정한 경우 음수 값은 허용되지 않습니다.
MySQL의 모든 계산은 배정밀도로 이루어지기 때문에 부동 소수점 숫자를 사용하면 예상치 못한 문제가 발생할 수 있습니다. A.5.7절. “일치하지 않는 행 문제 해결”을 참조하십시오.
· DOUBLE[(M,D)] [UNSIGNED] [ZEROFILL]
일반 크기(이중 정밀도) 부동 소수점 숫자입니다. 허용되는 값은 -1.7976931348623157E+308 ~ -2.2250738585072014E-308, 0 및 2.2250738585072014E-308 ~ 1.7976931348623157E+308입니다. 이는 IEEE 표준을 기반으로 한 이론적 한계입니다. 실제 범위는 하드웨어나 운영 체제에 따라 약간 더 작을 수 있습니다.
M은 전체 소수점 자릿수, D는 소수점 이하 자릿수입니다. M과 D를 생략하면 하드웨어에서 허용하는 제한에 따라 값이 저장됩니다. 배정밀도 부동 소수점 숫자는 소수점 이하 약 15자리까지 정확합니다.
UNSIGNED를 지정한 경우 음수 값은 허용되지 않습니다.
· DOUBLE PRECISION[(M,D)] [UNSIGNED] [ZEROFILL], REAL[(M,D)]
[UNSIGNED] [ZEROFILL]
은 DOUBLE의 동의어입니다. . 예외: SQL Server 모드에 REAL_AS_FLOAT 옵션이 포함된 경우 REAL은 DOUBLE의 동의어가 아니라 FLOAT의 동의어입니다.
· FLOAT(p) [UNSIGNED] [ZEROFILL]
부동 소수점 숫자입니다. p는 정밀도(비트로 표시)를 나타내지만 MySQL은 결과 열의 데이터 유형이 FLOAT인지 DOUBLE인지 확인하는 데에만 이 값을 사용합니다. p가 0에서 24 사이이면 데이터 유형은 M 또는 D 값 없이 FLOAT가 됩니다. p가 25에서 53 사이이면 데이터 유형은 M 또는 D 값 없이 DOUBLE이 됩니다. 결과 열 범위는 이 섹션의 앞부분에서 설명한 단정밀도 FLOAT 또는 배정밀도 DOUBLE 데이터 유형과 동일합니다.
FLOAT(p) 구문은 ODBC와 호환됩니다.
· DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL]
압축된 "엄격한" 고정 소수점 숫자. M은 전체 소수점 자릿수(정밀도)이고 D는 소수점 이하 자릿수(스케일)입니다. M에는 소수점과 '-' 기호(음수의 경우)가 포함되지 않습니다. D가 0이면 값에 소수점이나 분수 부분이 없습니다. DECIMAL 정수의 최대 자릿수(M)는 65입니다. 지원되는 최대 소수 자릿수(D)는 30개입니다. D를 생략하면
의 기본값은 0입니다. M을 생략하면 기본값은 10입니다.
UNSIGNED를 지정한 경우 음수 값은 허용되지 않습니다.
모든 DECIMAL 열(+, -, *, /)에 대한 기본 계산은 65비트 정밀도로 수행됩니다.
· DEC[(M[,D])] [UNSIGNED] [ZEROFILL], NUMERIC[(M[,D])]
[UNSIGNED] [ZEROFILL], FIXED[(M[, D])] [UNSIGNED] [ZEROFILL]
은 DECIMAL의 동의어입니다. FIXED 동의어는 다른 서버와의 호환성을 위해 적용됩니다.
11.1.2. 날짜 및 시간 유형 개요
이 섹션에서는 임시 열 유형에 대해 포괄적으로 설명합니다. 자세한 내용은 섹션 11.3, “날짜 및 시간 유형”을 참조하십시오. 컬럼 저장 요구 사항은 섹션 11.5, "컬럼 유형 저장 요구 사항"을 참조하세요.
·날짜
날짜. 지원되는 범위는 '1000-01-01'~'9999-12-31'입니다. MySQL은 DATE 값을 'YYYY-MM-DD' 형식으로 표시하지만 문자열이나 숫자를 사용하여 DATE 열에 값을 할당할 수 있습니다.
· DATETIME
날짜와 시간의 조합입니다. 지원되는 범위는 '1000-01-01 00:00:00' ~ '9999-12-31 23:59:59' 입니다. MySQL은 DATETIME 값을 'YYYY-MM-DD HH:MM:SS' 형식으로 표시하지만 문자열이나 숫자를 사용하여 DATETIME 열에 값을 할당할 수 있습니다.
· TIMESTAMP[(M)]
타임스탬프. 범위는 '1970-01-01 00:00:00'부터 2037년까지입니다.
TIMESTAMP 열은 INSERT 또는 UPDATE 작업 시 날짜와 시간을 기록하는 데 사용됩니다. 값을 할당하지 않으면 테이블의 첫 번째 TIMESTAMP 열이 자동으로 가장 최근 작업의 날짜와 시간으로 설정됩니다. NULL 값을 할당하여 TIMESTAMP 열을 현재 날짜 및 시간으로 설정할 수도 있습니다.
TIMESTAMP 값이 반환되어 'YYYY-MM-DD HH:MM:SS' 형식의 문자열로 표시됩니다. 표시 너비는 19자로 고정됩니다. 숫자 값을 얻으려면 TIMESTAMP 열에 +0을 추가하십시오.
참고: MySQL 4.1 이전에 사용된 TIMESTAMP 형식은 MySQL 5.1에서 지원되지 않습니다. 이전 형식에 대한 자세한 내용은 MySQL 4.1 참조 설명서를 참조하세요.
· 시간
시간. 범위는 '-838:59:59' ~ '838:59:59'입니다. MySQL은 'HH:MM:SS' 형식으로 TIME 값을 표시하지만 문자열이나 숫자를 사용하여 TIME 열에 값을 할당할 수 있습니다.
· 연도[(2|4)]
2자리 또는 4자리 형식의 연도입니다. 기본값은 4자리 형식입니다. 4자리 형식에서 허용되는 값은 1901~2155, 0000이다. 두 자리 형식에서 허용되는 값은 70~69이며, 이는 1970년부터 2069년까지의 연도를 나타냅니다. MySQL은 YYYY 형식으로 YEAR 값을 표시하지만 문자열이나 숫자를 사용하여 YEAR 열에 값을 할당할 수 있습니다.
11.1.3. 문자열 유형 개요
이 섹션에서는 문자열 열 유형에 대해 포괄적으로 설명합니다. 자세한 내용은 섹션 11.4, “문자열 유형”을 참조하십시오. 컬럼 저장 요구 사항은 섹션 11.5, "컬럼 유형 저장 요구 사항"을 참조하세요.
경우에 따라 MySQL은 문자열 열을 CREATE TABLE 또는 ALTER TABLE 문에 지정된 유형과 다른 유형으로 변경할 수 있습니다. 섹션 13.1.5.1, “자동 열 사양 변경”을 참조하십시오.
MySQL 5.1 문자열 데이터 유형에는 MySQL 4.1 이전 버전에서는 사용할 수 없었던 일부 기능이 포함되어 있습니다.
· 많은 문자열 데이터 유형에 대한 열 정의에는 문자를 지정하는 CHARACTER SET 속성이 포함될 수 있습니다. 설정하면 교정 규칙도 포함될 수 있습니다. (CHARSET은 CHARACTER SET의 동의어입니다). 이러한 속성은 CHAR, VARCHAR, TEXT 유형, ENUM 및 SET에 적용됩니다. 예:
이 테이블 정의는 utf8 문자 집합과 해당 문자 집합에 대한 기본 데이터 정렬을 사용하여 c1이라는 열과 The column이라는 열을 생성합니다. c2 및 latin1 문자 집합과 이 문자 집합의 이진 조합 규칙입니다. 이진 대조 규칙은 대소문자를 구분하지 않습니다.
· MySQL 5.1은 문자 열 정의의 길이 사양을 문자 단위로 해석합니다. (일부 이전 버전의 MySQL에서는 길이를 바이트 단위로 해석했습니다.)
· CHAR, VARCHAR 및 TEXT 유형의 경우 BINARY 속성은 열 문자 집합의 대조 규칙을 열에 할당할 수 있습니다.
· 문자 열은 해당 열에 할당된 문자 집합을 기준으로 정렬 및 비교됩니다. 이전 버전에서는 서버 문자 집합의 조합 규칙을 기반으로 정렬 및 비교가 이루어졌습니다. CHAR 및 VARCHAR 열의 경우 정렬 및 대조 규칙이 어휘 순서가 아닌 현재 문자 코드 값을 사용하도록 BINARY 속성을 사용하여 열을 선언할 수 있습니다.
MySQL 5.1의 문자 집합 지원에 대해서는 10장: 문자 집합 지원을 참조하세요.
· [NATIONAL] CHAR(M) [BINARY| ASCII | UNICODE]
고정 길이 문자열, 지정된 길이로 저장되면 오른쪽에 공백이 추가됩니다. M은 열 길이를 나타냅니다. M의 범위는 0~255자입니다.
참고: CHAR 값을 검색할 때 후행 공백이 제거됩니다.
CHAR 길이를 255보다 크게 설정하려는 경우 실행된 CREATE TABLE 또는 ALTER TABLE 문이 실패하고 오류 메시지가 표시됩니다.
CHAR는 CHARACTER의 약자입니다. NATIONAL CHAR(또는 이에 상응하는 약식 NCHAR)은 CHAR 열이 기본 문자 집합을 사용해야 함을 정의하는 표준 SQL 방법입니다. 이는 MySQL의 기본값입니다.
BINARY 속성은 지정된 열 문자 집합에 대한 이진 대조 규칙의 약어입니다. 정렬 및 비교는 숫자 값을 기반으로 합니다.
열 유형 CHAR BYTE는 CHAR BINARY의 별칭입니다. 이는 호환성을 보장하기 위한 것입니다.
CHAR에 ASCII 속성을 지정할 수 있습니다. latin1 문자 세트를 할당합니다.
CHAR에 UNICODE 속성을 지정할 수 있습니다. ucs2 문자 세트를 할당합니다.
MySQL에서는 CHAR(0) 유형의 열을 생성할 수 있습니다. 이는 주로 열이 있어야 하지만 실제로는 값을 사용하지 않는 이전 버전의 애플리케이션과의 호환성을 위한 것입니다. 두 개의 값만 사용할 수 있는 열이 필요한 경우에도 좋습니다. NOT NULL로 정의되지 않은 CHAR(0) 열은 1비트만 차지하고 NULL 및 "(빈 문자열) 값만 사용할 수 있습니다.
· CHAR
이것은 CHAR(1)의 동의어입니다. [NATIONAL] VARCHAR(M) [BINARY]
M은 최대 열 길이를 나타냅니다. 65,535(VARCHAR의 최대 실제 길이는 가장 긴 행의 크기와 사용된 문자 집합에 따라 결정됩니다. 최대 유효 길이는 65,532바이트입니다.) 참고: MySQL 5.1 표준 SQL 사양을 준수하며 VARCHAR 값에서 후행 공백을 제거하지 않습니다. .
VARCHAR은 문자 VARYING의 약어입니다.
BINARY 속성은 지정된 열의 문자 집합에 대한 이진 데이터 정렬의 약어입니다.
VARCHAR은 1바이트 또는 2바이트 길이 접두사 + 데이터로 저장됩니다. VARCHAR 열의 선언된 길이가 255보다 큰 경우 길이 접두사는
· BINARY(M)
BINARY 유형은 CHAR 유형과 유사하지만 이진이 아닌 문자열 대신 이진 바이트 문자열을 보유합니다.
· VARBINARY(M)
VARBINARY 유형은 다음과 유사합니다. VARCHAR 유형이지만 이진이 아닌 문자열
· TINYBLOB
최대 길이가 255(28–1)바이트인 BLOB입니다. >
· TINYTEXT
최대 길이가 255(28–1)자인 TEXT 열입니다.
· BLOB[(M)]
최대 A BLOB 길이가 65,535(216–1)바이트인 열.
에는 이 유형의 선택적 길이 M이 제공될 수 있습니다. 제공되면 MySQL은 가능한 한 작지만 M 바이트 길이를 보유할 수 있을 만큼 큰 열을 생성합니다. . BLOB 유형의 값입니다.
·TEXT[(M)]
최대 길이가 65,535(216–1)자인 TEXT 열을 지정할 수 있습니다. 선택적으로 길이 M. MySQL은 M자 길이의 값을 수용할 수 있을 만큼 큰 가장 작은 TEXT 유형으로 열을 생성합니다.
최대 길이는 16,777,215(224–1)바이트입니다. >
· MEDIUMTEXT
최대 길이가 16,777,215(224–1)자인 TEXT 열입니다.
· LONGBLOB
최대 길이는 4,294,967,295 또는 4GB입니다. 232–1) 바이트 BLOB 열. LONGBLOB 열의 최대 유효(허용) 길이는 클라이언트/서버 프로토콜에 구성된 최대 패킷 크기와 사용 가능한 메모리에 따라 달라집니다.
· LONGTEXT
최대 길이가 4,294,967,295 또는 4GB(232–1)자인 TEXT 열입니다. LONGTEXT 열의 최대 유효(허용) 길이는 클라이언트/서버 프로토콜에 구성된 최대 패킷 크기와 사용 가능한 메모리에 따라 달라집니다.
· ENUM('value1', 'value2',…)
열거형입니다. 값 열 'value1', 'value2', ..., NULL 또는 특수 "오류 값"에서 선택된 하나의 값만 가질 수 있는 문자열입니다. ENUM 열은 최대 65,535개의 고유 값을 가질 수 있습니다. 내부적으로 사용됩니다.
· SET('value1','value2',…)
문자열 개체는 0개 이상의 값을 가질 수 있으며, 각 값은 열 값에서 나와야 합니다. 'value1', 'value2', ... SET 열은 최대 64개 멤버를 가질 수 있습니다. SET 값은 내부적으로 정수
11.2로 표시됩니다. >MySQL은 모든 표준 SQL 숫자 데이터 유형을 지원합니다. 이러한 유형에는 엄격한 숫자 데이터 유형(INTEGER, SMALLINT, DECIMAL 및 NUMERIC)과 대략적인 숫자 데이터 유형(FLOAT, REAL 및 DOUBLE PRECISION)이 포함됩니다. INTEGER의 경우 DEC는 DECIMAL의 동의어입니다.
BIT 데이터 유형은 비트 필드 값을 저장하고 MyISAM, MEMORY, InnoDB 및 BDB 테이블을
지원합니다. SQL 표준인 MySQL은 정수 유형 TINYINT, MEDIUMINT 및 BIGINT도 지원합니다. 아래 표는 각 정수 유형에 필요한 저장 공간과 범위를 보여줍니다.
유형 바이트 최소값 최대값
( 서명됨/서명되지 않음) ( 서명됨/서명되지 않음)
TINYINT 1 -128 127
SMALLINT 2 -32768 32767
0 65535
MEDIUMINT 3 -8388608 8388607
0 16777215
INT 4 -2147483648 2147483647
0 4294967295
BIGINT 8 -9223372036854775808 9223372036854775807
0 18446744073709551615
MySQL은 type 키워드 뒤의 괄호 안에 정수 값의 표시 너비를 지정하는 옵션도 지원합니다(예: INT(4)). 선택적 표시 너비 지정은 표시 너비가 지정된 열 너비보다 작은 경우 왼쪽부터 너비를 채우는 데 사용됩니다.
표시 너비는 열 내에 저장할 수 있는 값의 범위를 제한하지 않으며, 열의 지정된 너비를 초과하는 값의 표시를 제한하지 않습니다.
선택적 확장 속성 ZEROFILL과 함께 사용하면 기본 보충 공백이 0으로 대체됩니다. 예를 들어, INT(5) ZEROFILL로 선언된 열의 경우 값 4는 00004로 검색됩니다. 표시된 너비를 초과하는 정수 열에 값을 저장하면 MySQL은 복잡한 조인을 위한 임시 테이블을 생성할 때 문제가 발생합니다. 이러한 경우 MySQL은 데이터가 원래 열 너비에 맞을 것이라고 믿기 때문입니다.
모든 정수 유형에는 UNSIGNED라는 선택적(비표준) 속성이 있을 수 있습니다. 부호 없는 값은 열에 음수가 아닌 숫자만 허용하고 열에 더 큰 상위 숫자 범위가 필요한 경우 사용할 수 있습니다.
부동 소수점 유형과 고정 소수점 유형도 UNSIGNED가 될 수 있습니다. 동일한 숫자 유형의 경우 이 속성을 사용하면 해당 열에 음수 값이 저장되지 않습니다. 그러나 정수형과 달리 열 값의 상위 범위는 변경되지 않습니다.
숫자 열에 ZEROFILL이 지정된 경우 MySQL은 자동으로 UNSIGNED 속성을 열에 추가합니다.
부동 소수점 열 유형의 경우 MySQL에서는 단정밀도 값은 4바이트를 사용하고 배정밀도 값은 8바이트를 사용합니다.
FLOAT 유형은 대략적인 숫자 데이터 유형을 나타내는 데 사용됩니다. SQL 표준을 사용하면 FLOAT 키워드 다음에 오는 괄호 안에 정밀도를 비트(지수 범위는 아님) 단위로 선택적으로 지정할 수 있습니다. MySQL은 또한 스토리지 크기를 결정하는 데만 사용되는 선택적 정밀도 사양을 지원합니다. 0에서 23까지의 정밀도는 FLOAT 열의 4바이트 단정밀도에 해당합니다. 24에서 53까지의 정밀도는 DOUBLE 열의 8바이트 배정밀도에 해당합니다.
MySQL에서는 FLOAT(M,D), REAL(M,D) 또는 DOUBLE
PRECISION(M,D)과 같은 비표준 구문을 사용할 수 있습니다. 여기서 "(M,D)"는 전체 M자리 정수를 표시하는 값을 의미하며, 소수점 이하 D자리가 위치한다. 예를 들어 FLOAT(7,4)로 정의된 열은 -999.9999로 표시될 수 있습니다. MySQL은 값을 저장할 때 반올림하므로 FLOAT(7,4) 열에 999.00009를 삽입하면 대략적인 결과는 999.0001이 됩니다.
MySQL은 DOUBLE을 DOUBLE PRECISION(비표준 확장)의 동의어로 취급합니다. 또한 MySQL은 SQL 서버 모드에 REAL_AS_FLOAT 옵션이 포함되어 있지 않으면 REAL을 DOUBLE PRECISION(비표준 확장)의 동의어로 처리합니다.
최대한의 이식성을 보장하려면 대략적인 숫자 데이터 값을 저장해야 하는 코드는 정밀도나 자릿수를 지정하지 않고 FLOAT 또는 DOUBLE PRECISION을 사용해야 합니다.
DECIMAL 및 NUMERIC 유형은 MySQL에서 동일한 유형으로 처리됩니다. 통화 데이터와 같이 정확해야 하는 값을 보유하는 데 사용됩니다. 이 유형의 열을 선언할 때 정밀도와 배율을 지정할 수 있습니다(일반적으로 그렇게 함). 예:
이 예에서 5는 정밀도이고 2는 배율입니다. 정밀도는 값에 저장할 수 있는 자릿수를 나타내고, 스케일은 소수점 이하 몇 자릿수를 저장할 수 있는지를 나타냅니다.
MySQL 5.1에서는 DECIMAL과 NUMERIC 값을 바이너리 형식으로 저장합니다.
표준 SQL에서는 급여 열에 정수 5자리와 소수점 이하 2자리의 값이 포함될 수 있어야 합니다. 따라서 이 경우 급여 항목에 저장할 수 있는 값의 범위는 -999.99부터 999.99까지이다.
표준 SQL에서 DECIMAL(M) 구문은 DECIMAL(M,0)과 동일합니다. 마찬가지로 DECIMAL 구문은 DECIMAL(M,0)과 동일하며 M의 값은 계산을 통해 결정될 수 있습니다. MySQL
5.1에서는 DECIMAL 및 NUMERIC 데이터 유형의 변수 형식이 지원됩니다. M의 기본값은 10입니다.
DECIMAL 또는 NUMERIC의 최대 자릿수는 65이지만 특정 DECIMAL 또는 NUMERIC 열의 실제 범위는 특정 열의 정밀도 또는 소수 자릿수에 의해 제한됩니다. 해당 열에 지정된 배율에서 허용되는 것보다 소수점 이하 자릿수가 더 많은 값이 할당되면 값이 해당 배율로 변환됩니다. (구체적인 작업은 운영 체제에 따라 다르지만 일반적으로 결과는 허용되는 자릿수로 잘립니다.)
BIT 데이터 유형을 사용하여 비트 필드 값을 저장할 수 있습니다. BIT(M) 유형을 사용하면 M 비트 값을 저장할 수 있습니다. M의 범위는 1부터 64까지입니다.
비트 값을 지정하려면 b'value' 기호를 사용할 수 있습니다. value는 0과 1로 쓰여진 이진 값입니다. 예를 들어 b'111'과 b'100000000'은 각각 7과 128을 나타냅니다. 섹션 9.1.5, “비트필드 값”을 참조하십시오.
BIT(M) 열에 할당된 값의 길이가 M비트 미만인 경우 값의 왼쪽을 0으로 채웁니다. 예를 들어, BIT(6) 열에 b'101' 값을 지정하면 b'000101'을 지정하는 것과 동일한 효과가 있습니다.
열의 허용 범위를 초과하는 값을 숫자 열에 저장하려는 경우 MySQL의 동작은 해당 시점에 적용되는 SQL 모드에 따라 달라집니다. 모드가 설정되지 않은 경우 MySQL은 값을 범위의 해당 끝점으로 자르고 잘린 값을 저장합니다. 그러나 모드가 Traditional("strict 모드")로 설정된 경우 범위를 벗어난 값은 오류와 함께 거부되며 SQL 표준에 따라 삽입이 실패합니다. 5.3.2절. “SQL Server 모드”를 참조하십시오.
INT 열이 UNSIGNED인 경우 열 범위의 크기는 동일하지만 해당 끝점은 0과 4294967295로 변경됩니다. -9999999999와 9999999999를 저장하려고 하면 Non-Strict 모드에서 해당 열에 저장된 값은 0과 4294967296입니다.
부동 소수점 또는 고정 소수점 열에 할당된 값이 지정된(또는 기본) 정밀도 및 배율로 지정된 범위를 초과하는 경우 MySQL은 범위의 해당 끝점을 나타내는 값을 비엄격하게 저장합니다. 방법.
MySQL이 엄격 모드에서 작동하지 않는 경우 클리핑으로 인한 변환은 ALTER TABLE, LOAD DATA INFILE, UPDATE 및 다중 행 INSERT 문에 대한 경고로 보고됩니다. MySQL이 엄격 모드에서 작동하는 경우 테이블이 트랜잭션인지 여부 및 기타 요인에 따라 이러한 명령문이 실패하고 일부 또는 모든 값이 삽입되거나 변경되지 않습니다. 자세한 내용은 섹션 5.3.2, "SQL Server 모드"를 참조하십시오.
11.3. 날짜 및 시간 유형
11.3.1. DATETIME, DATE 및 TIMESTAMP 유형 11.3.3. YEAR 유형 11.3.4. Y2K 사항 및 날짜 유형
시간 값을 나타내는 DATE 및 시간 유형은 다음과 같습니다. DATETIME, 날짜, 타임스탬프, 시간 및 연도. 각 시간 유형에는 유효한 값의 범위와 MySQL이 표현할 수 없는 잘못된 값을 지정할 때 사용되는 "0" 값이 있습니다. TIMESTAMP 유형에는 나중에 설명할 독점 자동 업데이트 기능이 있습니다.
잘못된 날짜를 삽입하려고 하면 MySQL에서 경고나 오류가 발생합니다. ALLOW_INVALID_DATES SQL 모드를 사용하여 MySQL이 '1999-11-31'과 같은 특정 날짜를 허용하도록 할 수 있습니다. 향후 처리를 위해 사용자가 데이터베이스(예: 웹 양식)에 지정한 "잘못되었을 수 있는" 값을 저장하려는 경우에 유용합니다. 이 모드에서 MySQL은 월 범위가 0~12이고 일 범위가 0~31인지만 확인합니다. MySQL에서는 DATE 또는 DATETIME 열에 일/월 및 일이 0인 날짜를 저장할 수 있으므로 이러한 범위에는 0이 포함될 수 있습니다. 이는 응용 프로그램이 정확한 날짜를 모르는 생일을 저장해야 할 때 유용합니다. 이 경우 날짜를 '1999-00-00′ 또는 '1999-01-00′으로 저장하시면 됩니다. DATE_SUB() 또는 DATE_ADD와 같이 완전한 날짜가 필요한 함수는 해당 날짜를 저장하면 올바른 결과를 제공하지 않습니다. (날짜에 0이 표시되는 것을 원하지 않으면 NO_ZERO_IN_DATE SQL 모드를 사용할 수 있습니다).
MySQL에서는 '0000-00-00'을 "의사 날짜"로 저장할 수도 있습니다(NO_ZERO_DATE SQL 모드를 사용하지 않는 경우). 어떤 경우에는 NULL 값을 사용하는 것보다 더 편리합니다(그리고 데이터와 인덱스가 더 적은 공간을 차지합니다).
SQL_mode 시스템 변수를 해당 모드 값으로 설정하면 MySQL이 어떤 종류의 날짜를 지원하길 원하는지 더 명확하게 알 수 있습니다. 5.3.2절. “SQL Server 모드”를 참조하십시오.
날짜 및 시간 유형으로 작업할 때 다음 사항에 유의해야 합니다.
· MySQL은 표준 출력 형식으로 지정된 날짜 또는 시간 유형의 값을 검색하지만 지정하는 각 값을 해석하는 것이 가장 좋습니다. 입력 값 형식(예: 날짜 또는 시간 유형에 할당되거나 비교되는 값을 지정하는 경우) 다음 섹션에 설명된 형식만 지원됩니다. 유효한 값을 제공하시기 바랍니다. 다른 형식의 값을 사용하면 예상치 못한 결과가 발생할 수 있습니다.
· 두 자리 연도 값이 포함된 날짜는 세기를 알 수 없기 때문에 모호합니다. MySQL은 다음 규칙을 사용하여 두 자리 연도 값을 해석합니다.
o 70-99 범위의 연도 값은 1970-1999로 변환됩니다.
o 00-69 범위의 연간 값은 2000-2069로 변환됩니다.
· MySQL은 여러 형식으로 값을 해석하려고 시도하지만 날짜는 항상 월-일-년이 아닌 연-월-일 순서(예: '98-09-04')입니다. 다른 곳에서는 일반적으로 사용됩니다. 또는 일-월-년 순서(예: '09-04-98', '04-09-98').
· MySQL은 값이 숫자 컨텍스트에서 사용되는 경우 날짜 또는 시간 유형 값을 자동으로 숫자로 변환하고 그 반대의 경우도 마찬가지입니다.
· MySQL이 해당 유형에 대해 범위를 벗어나거나 잘못된 날짜 또는 시간 유형 값을 발견하면(이 섹션 시작 부분에 설명된 대로) 해당 값을 해당 클래스의 "0" 값으로 변환합니다. . 한 가지 예외는 범위를 벗어난 TIME 값이 TIME 범위의 해당 끝점으로 잘린다는 것입니다.
다음 표는 다양한 "0" 값의 형식을 보여줍니다. NO_ZERO_DATE SQL 모드가 활성화된 경우 이 값을 사용하면 경고가 생성됩니다.
컬럼 유형 "0" 값
DATETIME '0000-00-00 00:00:00′
DATE '0000-00-00′
TIMESTAMP 00000000000000
TIME '00:00:00′
YEAR 0000
· "0" 값은 특별한 값이지만, 테이블 내 표시 값은 명시적으로 저장되거나 참조됩니다. 또한 '0' 또는 0 값을 사용하여 저장하거나 참조할 수 있으므로 작성하기가 더 쉽습니다.
· MyODBC에서 사용되는 "0" 날짜 또는 시간 값은 ODBC가 이러한 값을 처리할 수 없기 때문에 MyODBC 2.50.12 이상에서는 자동으로 NULL로 변환됩니다.
11.3.1. DATETIME, DATE, TIMESTAMP 유형
11.3.1.1.
MySQL 4.1 이후의 TIMESTAMP 속성
DATETIME, DATE, TIMESTAMP 유형은 서로 연관되어 있습니다. 이 섹션에서는 이들의 특징, 유사점 및 차이점을 설명합니다.
날짜와 시간 정보를 모두 포함하는 값이 필요한 경우 DATETIME 유형을 사용하세요. MySQL은 'YYYY-MM-DD HH:MM:SS' 형식으로 DATETIME 값을 검색하고 표시합니다. 지원되는 범위는 '1000-01-01 00:00:00' ~ '9999-12-31 23:59:59' 입니다. ("지원됨"은 이전 값이 작동할 수 있지만 보장할 수 없음을 의미합니다.)
DATE 타입은 시간 부분 없이 날짜 값만 필요한 경우에 사용해야 합니다. MySQL은 'YYYY-MM-DD' 형식을 사용하여 DATE 값을 검색하고 표시합니다. 지원되는 범위는 '1000-01-01'~'9999-12-31'입니다.
TIMESTAMP 열 유형의 속성은 고정되지 않으며 MySQL 버전과 서버가 실행 중인 SQL 모드에 따라 달라집니다. 이러한 속성은 이 섹션의 뒷부분에서 설명됩니다.
DATETIME, DATE 및 TIMESTAMP 값은 일반적인 형식을 사용하여 지정할 수 있습니다:
· 'YYYY-MM-DD HH:MM:SS' 또는 'YY-MM-DD HH: MM:SS '형식 문자열입니다. "완화된" 구문이 허용됩니다. 구두점 문자는 날짜 부분이나 시간 부분 사이의 구분 기호로 사용될 수 있습니다. 예를 들어 '98-12-31 11:30:45', '98.12.31 11+30+45', '98/12/31 11*30*45' 및 '98@12@31 11^30^ 45'는 동일합니다.
· 'YYYY-MM-DD' 또는 'YY-MM-DD' 형식의 문자열입니다. 여기서는 "Relaxed" 구문도 허용됩니다. 예를 들어 '98-12-31', '98.12.31', '98/12/31' 및 '98@12@31'은 동일합니다.
· 날짜 유형에 의미가 있는 문자열이라는 가정 하에 구분 기호 없이 'YYYYMMDDHHMMSS' 또는 'YYMMDDHHMMSS' 형식의 문자열입니다. 예를 들어 '19970523091528'과 '970523091528'은 '1997-05-23 09:15:28'로 해석되지만 '971122129015'는 불법(의미 없는 분 부분이 있음)이므로 '0000-00-00 00'이 됩니다. :00:00′.
· 구분 기호가 없는 'YYYYMMDD' 또는 'YYMMDD' 형식의 문자열(문자열이 날짜 유형에 의미가 있다고 가정). 예를 들어 '19970523'과 '970523'은 '1997-05-23'으로 해석되지만 '971332'는 불법(의미 없는 월과 일 부분이 있음)이므로 '0000-00-00'이 됩니다.
· YYYYMMDDHHMMSS 또는 YYMMDDHHMMSS 형식의 숫자(숫자가 날짜 유형에 적합하다고 가정). 예를 들어 19830905132800 및 830905132800은 '1983-09-05 13:28:00'으로 해석됩니다.
· YYYYMMDD 또는 YYMMDD 형식의 숫자(숫자가 날짜 유형에 적합하다고 가정). 예를 들어 19830905 및 830905는 '1983-09-05'로 해석됩니다.
· 함수가 반환한 결과 값은 NOW() 또는 CURRENT_DATE와 같은 DATETIME, DATE 또는 TIMESTAMP 컨텍스트에 적합합니다.
잘못된 DATETIME, DATE 또는 TIMESTAMP 값은 해당 유형('0000-00-00 00:00:00', '0000-00-00' 또는 00000000000000)의 "0" 값으로 변환됩니다. ).
날짜 부분 구분 기호가 포함된 문자열 값의 경우 일 및 월 값이 10 미만이면 두 자리를 지정할 필요가 없습니다. '1979-6-9'는 '1979-06-09'와 동일합니다. 마찬가지로 시간 부분 구분 기호가 포함된 문자열 값의 경우 시, 분, 초 값이 10보다 작으면 두 자리를 지정할 필요가 없습니다. '1979-10-30 1:2:3'은 '1979-10-30 01:02:03'과 동일합니다.
숫자값은 6, 8, 12, 14자리여야 합니다. 숫자 길이가 8자리 또는 14자리인 경우 YYYYMMDD 또는 YYYYMMDDHHMMSS 형식으로 간주되며 처음 4자리는 연도를 나타냅니다. 숫자가 6자리 또는 12자리인 경우 YYMMDD 또는 YYMMDDHHMMSS 형식으로 간주되며 처음 2자리는 연도를 나타냅니다. 다른 숫자는 가장 가까운 길이까지 0으로 채워진 것처럼 해석됩니다.
한정자가 아닌 문자열로 지정된 값은 주어진 길이를 사용하여 해석됩니다. 문자열 길이가 8자 또는 14자인 경우 처음 4자리는 연도를 나타냅니다. 그렇지 않은 경우 처음 두 자리는 연도를 나타냅니다. 문자열 내에서 발생하는 각 구성요소를 왼쪽에서 오른쪽으로 해석하여 연도, 월, 일, 시, 분, 초 값을 알아냅니다. 즉, 6자보다 짧은 문자열은 사용하면 안 됩니다. 예를 들어, '9903'을 지정하고 1999년 3월을 의미한다고 생각하면 MySQL은 테이블에 "0" 날짜 값을 삽입합니다. 연도와 월의 값이 99와 03인데 일 부분이 완전히 빠졌기 때문에 그 값은 법적 날짜가 아니기 때문이다. 그러나 누락된 월 또는 일 부분을 나타내기 위해 명시적으로 0 값을 지정할 수 있습니다. 예를 들어 '990300'을 사용하여 '1999-03-00' 값을 삽입할 수 있습니다.
어느 정도까지는 한 날짜 유형의 값을 다른 날짜 유형에 할당할 수 있습니다. 그러나 값이 변경되거나 일부 정보가 손실될 수 있습니다.
· DATETIME 또는 TIMESTAMP 객체에 DATE 값을 할당하면 결과 값의 시간 부분이 '00:00:00'으로 설정됩니다. DATE 값에는 시간 정보가 포함되어 있지 않습니다.
· DATE 객체에 DATETIME 또는 TIMESTAMP 값을 할당하면 DATE 값에 시간 정보가 포함되어 있지 않으므로 결과 값의 시간 부분이 제거됩니다.
· DATETIME, DATE, TIMESTAMP 값은 동일한 형식을 사용하여 지정할 수 있지만 값 유형에 따라 범위가 다르다는 점을 기억하세요. 예를 들어 TIMESTAMP 값은 1970년 이전이거나 2037년 이후일 수 없습니다. 이는 '1968-01-01'과 같은 날짜가 DATETIME 또는 DATE 값에는 유효하지만 TIMESTAMP 값에는 유효하지 않으며 해당 객체에 할당되면 0으로 변환됨을 나타냅니다.
날짜 값을 지정할 때 주의할 점:
· 문자열로 지정된 값에 허용되는 엄격하지 않은 형식은 기만적일 수 있습니다. 예를 들어 '10:11:12' 값은 ':' 구분 기호로 인해 시간 값처럼 보일 수 있지만 날짜 컨텍스트 값에 사용되면 '2010-11-12' 연도로 해석됩니다. '10:45:15' 값은 '45'가 법정 월이 아니기 때문에 '0000-00-00'으로 변환됩니다.
· 비엄격 모드에서 MySQL 서버는 날짜의 유효성에 대한 기본 검사만 수행합니다. 연도, 월, 일의 범위는 각각 1000~9999, 00~12, 00~31입니다. 이 범위를 벗어나는 부분이 포함된 날짜는 '0000-00-00'으로 변환됩니다. '2002-04-31'과 같은 잘못된 날짜를 저장할 수는 있습니다. 엄격 모드를 사용하지 않을 때 날짜가 유효한지 확인하려면 애플리케이션을 확인해야 합니다.
엄격 모드에서는 잘못된 날짜가 허용되지 않으며 변환되지 않습니다.
자세한 내용은 섹션 5.3.2, "SQL Server 모드"를 참조하세요.
· 두 자리 연도 값이 포함된 날짜는 세기를 알 수 없기 때문에 모호합니다. MySQL은 다음 규칙을 사용하여 두 자리 연도 값을 해석합니다.
o 00-69 범위의 연도 값은 2000-2069로 변환됩니다.
o 70-99 범위의 연간 값은 1970-1999로 변환됩니다.
11.3.1.1. MySQL 4.1 이후의 TIMESTAMP 속성
참고: 이전 버전의 MySQL(4.1 이전)에서는 TIMESTAMP 열 유형의 속성이 여러 개였습니다. 방법 이 섹션에 설명된 내용과 매우 다릅니다. MySQL 5.1에서 작동하도록 이전 TIMESTAMP 데이터를 변환해야 하는 경우 자세한 내용은 MySQL 4.1 참조 설명서를 참조하세요.
TIMESTAMP 열의 표시 형식은 DATETIME 열의 표시 형식과 동일합니다. 즉, 표시 너비는 19자로 고정되고 형식은 YYYY-MM-DD HH:MM:SS입니다.
MySQL 서버는 MAXDB 모드에서도 실행될 수 있습니다. 서버가 이 모드로 실행 중이면 TIMESTAMP는 DATETIME과 같습니다. 즉, 테이블 생성 시 서버가 MAXDB 모드로 실행 중이면 TIMESTAMP 컬럼이 DATETIME 컬럼으로 생성된다. 결과적으로 열은 DATETIME 표시 형식을 사용하고, 값 범위가 동일하며, 현재 날짜 및 시간으로 자동으로 초기화되거나 업데이트되지 않습니다.
MAXDB 모드를 활성화하려면 서버를 시작할 때 –sql-mode=MAXDB 서버 옵션을 사용하거나 전역 sql_mode 변수를 설정하여 런타임 시 SQL 서버 모드를 MAXDB로 설정하세요.
클라이언트는 다음과 같이 연결을 위해 MAXDB 모드에서 서버를 실행할 수 있습니다.
MySQL은 다음 형식의 파일을 허용하지 않습니다. 일본 또는 월 열에 0 또는 잘못된 날짜 값이 포함된 타임스탬프 값이 포함되어 있습니다. 이 규칙의 유일한 예외는 특수 값 '0000-00-00 00:00:00′입니다.
TIMESTAMP를 초기화하고 업데이트할 시기와 초기화하고 업데이트할 열을 매우 유연하게 결정할 수 있습니다.
· 현재 타임스탬프를 기본값으로 지정하고 자동으로 업데이트되는 값을 지정할 수 있습니다. 하지만 하나만 선택할 수도 있고 둘 다 선택할 수도 없습니다. (한 열이 하나의 동작을 선택하고 다른 열이 다른 동작을 선택하는 것은 불가능합니다.)
· 현재 날짜 및 시간으로 자동으로 초기화되거나 업데이트되는 TIMESTAMP 열을 지정할 수 있습니다. 첫 번째 TIMESTAMP 열은 더 이상 필요하지 않습니다.
아래에 설명된 정보는 MAXDB 모드를 활성화하지 않고 생성된 테이블의 TIMESTAMP 열에만 적용된다는 점에 유의하세요. (위에서 언급한 것처럼 MAXDB 모드를 사용하면 열이 DATETIME 열로 생성됩니다.) TIMESTAMP 컬럼의 초기화 및 업데이트를 제어하는 규칙은 다음과 같습니다.
· 테이블의 첫 번째 TIMESTAMP 컬럼이 DEFAULT 값으로 지정된 경우 무시할 수 없습니다. 기본값은 CURRENT_TIMESTAMP 또는 상수 날짜 및 시간 값일 수 있습니다.
· DEFAULT NULL은 첫 번째 TIMESTAMP 열의 DEFAULT CURRENT_TIMESTAMP와 동일합니다. 다른 TIMESTAMP 열의 경우 DEFAULT NULL은 DEFAULT 0으로 처리됩니다.
· 테이블의 모든 TIMESTAMP 열은 현재 타임스탬프 및/또는 업데이트로 자동 초기화되도록 설정할 수 있습니다.
· CREATE TABLE 문에서 다음 방법 중 하나로 첫 번째 TIMESTAMP 열을 선언할 수 있습니다.
o 기본값을 사용하려면 DEFAULT CURRENT_TIMESTAMP 및 ON UPDATE CURRENT_TIMESTAMP 절을 사용하세요. 현재 타임스탬프가 자동으로 업데이트됩니다.
o DEFAULT CURRENT_TIMESTAMP ON UPDATECURRENT_TIMESTAMP와 마찬가지로 DEFAULT 또는 ON UPDATE 절을 사용하지 않습니다.
o ON UPDATE 절 대신 DEFAULT CURRENT_TIMESTAMP 절을 사용합니다. 열은 현재 타임스탬프를 기본값으로 사용하지만 자동으로 업데이트되지 않습니다.
o DEFAULT 절은 없지만 ON UPDATE CURRENT_TIMESTAMP 절이 있는 경우 열의 기본값은 0이며 자동으로 업데이트됩니다.
o 주어진 기본값이 나열된 상수 DEFAULT 값을 사용합니다. 열에 ON UPDATE CURRENT_TIMESTAMP 절이 있으면 자동으로 업데이트되고 그렇지 않으면 업데이트되지 않습니다.
즉, 초기 값과 자동 업데이트 값에 현재 타임스탬프를 사용하거나 둘 중 하나를 사용하거나 둘 다 사용하지 않을 수 있습니다. (예를 들어 ON UPDATE를 지정하면 열을 자동으로 초기화하지 않고도 자동 업데이트를 활성화할 수 있습니다.)
· DEFAULT 및 ON UPDATE 절에 CURRENT_TIMESTAMP, CURRENT_TIMESTAMP() 또는 NOW()를 사용할 수 있습니다. 모두 동일한 효과가 있습니다.
두 속성의 순서는 중요하지 않습니다. TIMESTAMP 열에 DEFAULT와 ON UPDATE가 모두 지정된 경우 둘 중 하나가 다른 것 앞에 올 수 있습니다.
예를 들어 다음 명령문은 동일합니다.
· 열 1이 아닌 TIMESTAMP 열에 대해 자동 기본값 또는 업데이트를 지정하려면 첫 번째 TIMESTAMP 열에 상수 DEFAULT 값을 명시적으로 할당하여 자동 초기화 및 업데이트를 비활성화해야 합니다. (예: DEFAULT 0 또는 DEFAULT'2003-01-01 00:00:00′). 그런 다음 다른 TIMESTAMP 열의 경우 규칙은 DEFAULT 및 ON UPDATE 절을 무시할 수 없다는 점을 제외하고 첫 번째 TIMESTAMP 열과 동일합니다. 이렇게 하면 초기화나 업데이트가 자동으로 발생하지 않습니다.
예: 다음 명령문은 동일합니다.
각 연결에 대해 현재 시간대를 설정할 수 있습니다. 관련 설명은 섹션 5.10.8, "MySQL 서버 시간대 지원"을 참조하십시오. TIMESTAMP 값은 UTC 형식으로 저장되며, 저장 시 현재 시간대로 변환되고, 검색 시 다시 현재 시간대로 변환됩니다. 타임존 설정 값이 일정하면 저장 당시의 값을 얻을 수 있습니다. TIMESTAMP 값을 저장한 경우 시간대를 변경한 후 값을 검색해야 하며, 저장한 값과 다릅니다. 이는 양방향 변환에 동일한 시간대를 사용하지 않기 때문입니다. 현재 시간대를 time_zone 시스템 변수의 값으로 사용할 수 있습니다.
TIMESTAMP 열 정의에 NULL 속성을 포함하면 열에 NULL 값이 포함될 수 있습니다. 예:
NULL 속성이 지정되지 않은 경우 열을 NULL로 설정하면 현재 타임스탬프로 설정됩니다. NULL 값을 허용하는 TIMESTAMP 열은 기본값이 CURRENT_TIMESTAMP로 정의되거나 NOW() 또는 CURRENT_TIMESTAMP가 열에 삽입되지 않는 한 현재 타임스탬프를 가정하지 않습니다. 즉, NULL로 정의된 TIMESTAMP 열은 다음을 사용하여 생성된 경우에만 자동으로 업데이트됩니다.
그렇지 않은 경우, 즉 DEFAULT TIMESTAMP 대신 NULL이 사용되는 경우 TIMESTAMP 열을 다음과 같이 정의하려면...
... 그런 다음 현재 날짜 및 시간에 해당하는 값을 명시적으로 삽입해야 합니다. 예:
11.3.2. TIME 유형
MySQL은 'HH:MM:'에서 TIME 값을 검색하고 표시합니다. SS' 형식(또는 큰 시간 값의 경우 'HHH:MM:SS' 형식). TIME 값은 '-838:59:59'부터 '838:59:59'까지 가능하다. 시간 부분이 너무 큰 이유는 TIME 유형을 사용하여 하루 중 시간(24시간 미만이어야 함)을 나타낼 수 있을 뿐만 아니라 이벤트가 경과한 시간이나 두 시간 사이의 시간 간격도 나타낼 수 있기 때문입니다. 이벤트(24시간보다 길거나 음수일 수도 있음).
TIME 값은 다양한 형식으로 지정할 수 있습니다.
· 'D HH:MM:SS.fraction' 형식의 문자열. 다음과 같은 "엄격하지 않은" 구문을 사용할 수도 있습니다: 'HH:MM:SS.fraction', 'HH:MM:SS', 'HH:MM', 'D HH:MM:SS', 'D HH: MM', 'D HH' 또는 'SS'. 여기서 D는 일을 나타내며 0에서 34 사이의 값을 가질 수 있습니다. MySQL은 아직 점수를 저장하지 않습니다.
· 의미 있는 시간을 가정하여 구분 기호 없이 'HHMMSS' 형식의 문자열입니다. 예를 들어 '101112'는 '10:11:12'로 이해되지만 '109712'는 불법(의미 없는 분 부분이 있음)이므로 '00:00:00'이 됩니다.
· HHMMSS 형식의 값으로, 의미 있는 시간으로 가정됩니다. 예를 들어 101112는 '10:11:12'로 이해됩니다. SS, MMSS, HHMMSS, HHMMSS.fraction 형식도 인식됩니다. MySQL은 아직 점수를 저장하지 않습니다.
· CURRENT_TIME과 같이 TIME 컨텍스트에 적합한 값을 사용하여 함수가 반환한 결과입니다.
시간 부분 구분 기호를 포함하여 문자열로 지정된 TIME 값의 경우 시, 분, 초 값이 10 미만이면 두 자리를 지정할 필요가 없습니다. '8:3:2'는 '08:03:02'와 같습니다.
TIME 열에 약식 값을 할당할 때는 주의해야 합니다. 콜론이 없으면 MySQL은 가장 오른쪽 두 자리가 초를 나타낸다고 가정하여 값을 해석합니다. (MySQL은 TIME 값을 오늘 시간이 아닌 과거 시간으로 해석합니다.) 예를 들어 '1112'와 1112는 '11:12:00'(11시 12분)을 의미한다고 생각할 수 있지만 MySQL은 이를 '00:11:12'(11분 12초)로 해석합니다. 마찬가지로 '12'와 12는 '00:00:12'로 해석됩니다. 대조적으로, TIME 값의 콜론은 항상 시간으로 간주됩니다. 즉, '11:12'는 '00:11:12'가 아니라 '11:12:00'을 의미합니다.
TIME 범위를 벗어나지만 유효한 값은 범위의 가장 가까운 끝점으로 잘립니다. 예를 들어 '-850:00:00'과 '850:00:00'은 '-838:59:59'와 '838:59:59'로 변환됩니다.
잘못된 TIME 값은 '00:00:00'으로 변환됩니다. '00:00:00' 자체는 유효한 TIME 값이므로, 테이블에 저장된 '00:00:00' 값만으로는 원래 값이 '00:00:00'인지 불법적인 값인지 알 수 없다는 점에 유의하시기 바랍니다. .
11.3.3년형
YEAR 유형은 연도를 나타내는 데 사용되는 싱글바이트 유형입니다.
MySQL은 YYYY 형식으로 YEAR 값을 검색하고 표시합니다. 범위는 1901~2155입니다.
YEAR 값을 다양한 형식으로 지정할 수 있습니다.
· '1901'부터 '2155'까지의 4자리 문자열.
· 1901부터 2155까지의 네 자리 숫자입니다.
· '00'부터 '99'까지의 두 자리 문자열입니다. '00'~'69' 및 '70'~'99' 범위의 값은 2000~2069 및 1970~1999 범위의 YEAR 값으로 변환됩니다.
· 1~99 범위의 두 자리 정수. 1~69 및 70~99 범위의 값은 2001~2069 및 1970~1999 범위의 YEAR 값으로 변환됩니다. 두 자리 정수 범위는 0을 숫자로 직접 지정하고 2000으로 해석할 수 없다는 점에서 두 자리 문자열 범위와 약간 다릅니다. 문자열 '0' 또는 '00'으로 지정해야 합니다. 그렇지 않으면 0000으로 해석됩니다.
· NOW()와 같이 YEAR 컨텍스트에 적합한 값을 갖는 함수에서 반환된 결과입니다.
잘못된 YEAR 값은 0000으로 변환됩니다.
11.3.4. Y2K 사항 및 날짜 유형
MySQL은 본질적으로 2000년(Y2K)에도 안전합니다(섹션 1.4.5, "Y2K 호환성" 참조). , 그러나 MySQL에 입력된 값은 안전하지 않을 수 있습니다. 두 자리 연도 값을 포함하는 모든 입력은 세기를 알 수 없기 때문에 모호합니다. MySQL은 내부적으로 연도를 저장하기 위해 4자리 숫자를 사용하기 때문에 이러한 값은 4자리 숫자로 해석되어야 합니다.
DATETIME, DATE, TIMESTAMP, YEAR 유형의 경우 MySQL은 다음 규칙을 사용하여 모호한 연도 값이 있는 날짜를 해석합니다.
· 00-69 범위의 연도 값이 변환됩니다. 2000-2069년까지.
· 70~99 범위의 연간 값을 1970~1999로 변환합니다.
이러한 규칙은 데이터 값이 나타내는 내용에 대한 합리적인 추측일 뿐이라는 점을 기억하세요. MySQL에서 사용하는 경험적 방법이 올바른 값을 생성하지 못하는 경우 4자리 연도 값이 포함된 정확한 입력을 제공해야 합니다.
ORDER BY는 TIMESTAMP 또는 YEAR 값을 연도 두 자리로 올바르게 정렬할 수 있습니다.
MIN() 및 MAX()와 같은 일부 함수는 TIMESTAMP 또는 YEAR를 숫자로 변환합니다. 이는 두 자리 연도 값을 갖는 값에서는 이러한 함수가 올바르게 작동하지 않음을 의미합니다. 이 경우 해결 방법은 TIMESTAMP 또는 YEAR를 4자리 연도 형식으로 변환하거나 MIN(DATE_ADD(TIMESTAMP,INTERVAL 0 DAYS))를 사용하는 것입니다.
11.4. 문자열 유형
11.4.1.CHAR 및 VARCHAR 유형 11.4.2.
BLOB 및 TEXT 유형
11.4.4. ENUM 유형 11.4.5. SET 유형
문자열 유형은 CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM 및 SET을 의미합니다. 이 섹션에서는 이러한 유형의 작동 방식과 쿼리에서 이를 사용하는 방법을 설명합니다.
11.4.1. CHAR 및 VARCHAR 유형
CHAR 및 VARCHAR 유형은 유사하지만 저장 및 검색이 다릅니다. 또한 최대 길이와 후행 공백이 유지되는지 여부도 다릅니다. 저장 또는 검색 중에는 대소문자 변환이 수행되지 않습니다.
CHAR 및 VARCHAR 유형에 대해 선언된 길이는 저장하려는 최대 문자 수를 나타냅니다. 예를 들어 CHAR(30)은 30자를 차지할 수 있습니다.
CHAR 컬럼의 길이는 테이블 생성 시 선언한 길이로 고정됩니다. 길이는 0에서 255 사이의 값일 수 있습니다. CHAR 값을 저장할 때 지정된 길이만큼 공백으로 오른쪽을 채웁니다. CHAR 값이 검색되면 후행 공백이 제거됩니다. 저장 또는 검색 중에는 대소문자 변환이 수행되지 않습니다.
VARCHAR 열의 값은 가변 길이 문자열입니다. 길이는 0에서 65,535 사이의 값으로 지정할 수 있습니다. (VARCHAR의 최대 유효 길이는 최대 행 크기와 사용된 문자 세트에 따라 결정됩니다. 전체 최대 길이는 65,532바이트입니다.)
CHAR과 비교하여 VARCHAR 값을 저장할 때 필요한 문자 수만큼만 저장하고 길이를 기록하기 위해 1바이트를 추가합니다(선언된 컬럼 길이가 255를 초과하는 경우 2바이트를 사용합니다).
VARCHAR 값은 패딩 없이 저장됩니다. 표준 SQL에 따라 값을 저장하고 검색할 때 후행 공백이 유지됩니다.
CHAR 또는 VARCHAR 열에 할당된 값이 열의 최대 길이를 초과하는 경우 값이 해당 열에 맞게 잘립니다. 잘린 문자가 공백이 아닌 경우 경고가 생성됩니다. 공백이 아닌 문자가 잘리면 (경고 대신) 오류가 발생하고 엄격한 SQL 모드를 사용하여 값 삽입이 비활성화됩니다. 5.3.2절. “SQL Server 모드”를 참조하십시오.
다음 표는 다양한 문자열 값을 CHAR(4) 및 VARCHAR(4) 열에 저장한 결과를 보여주며, CHAR과 VARCHAR의 차이점을 보여줍니다.
값 CHAR (4) 저장 요구사항 VARCHAR(4) 저장 요구사항
” ' ' 4바이트 ” 1바이트
'ab' 'ab ' 4바이트 ' ab ' 3바이트
'abcd' 'abcd' 4바이트 'abcd' 5바이트
'abcdefgh' 'abcd' 4바이트 'abcd' 5바이트 바이트
위 표는 엄격 모드를 사용하지 않는 경우에만 적용되며, MySQL을 엄격 모드로 실행하는 경우 해당 열 길이를 초과하는 값은 저장되지 않으며 오류가 발생합니다.
CHAR(4) 및 VARCHAR(4) 열에서 검색된 값은 검색 시 CHAR 열에서 후행 공백이 제거되므로 항상 동일하지는 않습니다. 다음 예에서는 차이점을 보여줍니다.
해당 열에 할당된 문자 집합 조합 규칙에 따라 CHAR 및 VARCHAR 열의 값을 정렬하고 비교합니다.
모든 MySQL 데이터 정렬 규칙은 PADSPACE 클래스에 속합니다. 이는 MySQL의 모든 CHAR 및 VARCHAR 값을 비교할 때 후행 공백을 고려할 필요가 없음을 의미합니다. 예:
이는 모든 MySQL 버전에 해당되며 다음의 영향을 받지 않습니다. SQL 서버 모드.
비교 중에 뒤따르는 패딩 문자가 잘리거나 무시되는 경우, 열 인덱스에 고유한 값이 필요한 경우 패딩 문자 수만 다른 열에 값을 삽입하면 중복 키가 발생합니다. 가치관 실수.
CHAR BYTE는 CHAR BINARY의 별칭입니다. 이는 호환성을 보장하기 위한 것입니다.
ASCII 속성은 latin1 문자 세트를 CHAR 열에 할당합니다. UNICODE 속성은 ucs2 문자 세트를 할당합니다.
11.4.2. BINARY 및 VARBINARY 유형
BINARY 및 VARBINARY 클래스는 이진이 아닌 문자열 대신 이진 문자열을 포함한다는 점을 제외하면 CHAR 및 VARCHAR과 유사합니다. . 즉, 문자열이 아닌 바이트 문자열을 포함합니다. 이는 문자 세트가 없으며 정렬 및 비교가 열 값 바이트의 숫자 값을 기반으로 함을 의미합니다.
BINARY와 VARBINARY의 최대 허용 길이는 CHAR, VARCHAR과 마찬가지로 동일합니다. 차이점은 BINARY와 VARBINARY의 길이는 문자 길이가 아닌 바이트 길이입니다.
BINARY 및 VARBINARY 데이터 유형은 CHAR BINARY 및 VARCHAR BINARY 데이터 유형과 다릅니다. 후자 유형의 경우 BINARY 속성은 열을 이진 문자열 열로 처리하지 않습니다. 대신 열 문자 집합의 이진 데이터 정렬 규칙이 사용되고 열 자체에는 이진 바이트 문자열이 아닌 이진이 아닌 문자열이 포함됩니다. 예를 들어, CHAR(5) BINARY는 기본 문자 집합이 latin1이라고 가정할 때 CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin으로 처리됩니다. 이는 문자 집합이나 조합 규칙 없이 5바이트 이진 문자열을 보유하는 BINARY(5)와 다릅니다.
BINARY 값을 저장할 때 오른쪽에 지정된 길이의 값을 채워 넣습니다. 패딩 값은 0×00(0바이트)입니다. 값을 삽입할 때 오른쪽에 0×00을 추가하고 선택 시 후행 바이트를 삭제하지 않습니다. ORDER BY 및 DISTINCT 작업을 포함하여 비교할 때 모든 바이트가 중요합니다. 비교해 보면 0×00바이트와 공백은 다르며, 0×00
예: BINARY(3) 열의 경우 'a'는 삽입 시 'a'가 됩니다. 'a'를 삽입하면 'a'가 됩니다. 선택한 경우 삽입된 값이 변경되지 않습니다.
VARBINARY의 경우 삽입 시 문자가 채워지지 않으며 선택 시 바이트가 잘리지 않습니다. ORDER BY 및 DISTINCT 작업을 포함하여 비교할 때 모든 바이트가 중요합니다. 비교해 보면 0×00바이트와 공백은 다르며, 0×00
비교 중에 뒤따르는 패딩 문자가 잘리거나 무시되는 경우, 열 인덱스에 고유한 값이 필요한 경우 패딩 문자 수만 다른 열에 값을 삽입하면 중복 키가 발생합니다. 가치관 실수.
이러한 데이터 유형을 사용하여 바이너리 데이터를 저장할 계획이고 저장된 값과 정확히 동일한 값을 검색해야 하는 경우 앞서 설명한 패딩 및 클리핑 기능을 고려해야 합니다. 다음 예에서는 0×00으로 채워진 BINARY 값이 열 값 비교에 어떻게 영향을 미치는지 보여줍니다. 검색된 값은 패딩 없이 저장하기 위해 지정된 값과 동일해야 하며 가급적 BLOB 데이터 유형을 사용하는 것이 좋습니다.
MySQL은 테이블을 생성할 때 BINARY 또는 VARBINARY 열의 유형을 자동으로 변경할 수 있습니다. 섹션 13.1.5.1, “자동 열 사양 변경”을 참조하십시오.
11.4.3 BLOB 및 TEXT 유형
BLOB는 가변적인 양의 데이터를 담을 수 있는 바이너리 대형 객체입니다. BLOB 유형에는 TINYBLOB, BLOB, MEDIUMBLOB 및 LONGBLOB의 4가지가 있습니다. 값을 저장할 수 있는 최대 길이만 다릅니다.
TINYTEXT, TEXT, MEDIUMTEXT 및 LONGTEXT의 4가지 TEXT 유형이 있습니다. 이는 최대 길이와 저장 요구 사항이 동일한 4가지 BLOB 유형에 해당합니다.
섹션 11.5, "컬럼 유형 보관 요구 사항"을 참조하세요.
BLOB 열은 이진 문자열(바이트 문자열)로 처리됩니다. TEXT 열은 이진이 아닌 문자열(문자열)로 처리됩니다. BLOB 컬럼에는 문자 집합이 없으며 정렬 및 비교는 컬럼 값 바이트의 숫자 값을 기반으로 수행됩니다. TEXT 열에는 문자 집합이 있으며 해당 문자 집합의 대조 규칙에 따라 값이 정렬되어 비교됩니다.
TEXT 또는 BLOB 열을 저장하거나 검색하는 동안 대소문자 변환은 없습니다.
엄격 모드로 실행하지 않을 때 BLOB 또는 TEXT 열에 해당 열 유형의 최대 길이를 초과하는 값을 할당하면 값이 그에 맞게 잘립니다. 잘린 문자가 공백이 아닌 경우 경고가 생성됩니다. 엄격한 SQL 모드를 사용하면 오류가 생성되고 경고와 함께 차단되는 대신 값이 거부됩니다. 5.3.2절. “SQL Server 모드”를 참조하십시오.
대부분의 측면에서 BLOB 열은 충분히 클 수 있는 VARBINARY 열로 간주할 수 있습니다. 마찬가지로 TEXT 열은 VARCHAR 열로 처리될 수 있습니다. BLOB 및 TEXT는 다음과 같은 점에서 VARBINARY 및 VARCHAR와 다릅니다.
· BLOB 및 TEXT 열에서 값을 저장하거나 검색할 때 후행 공백이 제거되지 않습니다. (이는 VARBINARY 및 VARCHAR 열과 동일합니다.)
TEXT는 CHAR 및 VARCHAR과 마찬가지로 비교 대상에 맞게 공백으로 확장됩니다.
· BLOB 및 TEXT 컬럼의 인덱스의 경우 인덱스 접두어의 길이를 지정해야 합니다. CHAR 및 VARCHAR의 경우 접두사 길이는 선택 사항입니다. 7.4.3절. “열 인덱스”를 참조하십시오.
· BLOB 및 TEXT 열은 기본값을 가질 수 없습니다.
LONG 및 LONG VARCHAR은 MEDIUMTEXT 데이터 유형에 해당합니다. 이는 호환성을 보장하기 위한 것입니다. TEXT 열 유형이 BINARY 속성을 사용하는 경우 해당 열에는 열 문자 집합의 이진 데이터 정렬이 할당됩니다.
MySQL 커넥터/ODBC는 BLOB 값을 LONGVARBINARY로, TEXT 값을 LONGVARCHAR로 정의합니다.
BLOB 및 TEXT 값은 매우 길 수 있으므로 사용 시 몇 가지 제약이 발생할 수 있습니다.
· 정렬 시 열의 첫 번째 max_sort_length 바이트만 사용됩니다. max_sort_length의 기본값은 1024입니다. 이 값은 mysqld 서버를 시작할 때 –max_sort_length 옵션을 사용하여 변경할 수 있습니다. 섹션 5.3.3, "서버 시스템 변수"를 참조하십시오.
런타임 시 max_sort_length 값을 늘리면 정렬 또는 결합 시 더 많은 바이트를 의미 있게 만들 수 있습니다. 모든 클라이언트는 해당 세션 max_sort_length 변수의 값을 변경할 수 있습니다.
max_sort_length보다 긴 바이트를 이해하려는 경우, 맞습니다. 다른 방법 긴 값을 포함하는 BLOB 또는 TEXT 열에 대해 GROUP BY 또는 ORDER BY를 사용하는 것은 열 값을 고정 길이 객체로 변환하는 것입니다. 표준 접근 방식은 SUBSTRING 함수를 사용하는 것입니다. 예를 들어 다음 명령문은 설명 열의 2000바이트를 정렬합니다. 클라이언트와 서버 간에 전송할 수 있는 실제 최대 값은 사용 가능한 메모리 양과 통신 버퍼 크기에 따라 결정됩니다. max_allowed_packet 변수의 값을 변경하여 메시지 버퍼의 크기를 변경할 수 있지만 서버 프로그램과 클라이언트 프로그램을 모두 수정해야 합니다. 예를 들어, mysql 및 mysqldump를 사용하여 클라이언트의 max_allowed_packet 값을 변경할 수 있습니다. 섹션 7.5.2, "서버 매개변수 조정", 섹션 8.3, "mysql: MySQL 명령줄 도구" 및 섹션 8.8, "mysqldump: 데이터베이스 백업 프로그램"을 참조하세요.
각 BLOB 또는 TEXT 값은 각각 내부적으로 할당된 개체로 표시됩니다. 이는 테이블이 열릴 때 각 열에 스토리지 엔진을 할당하는 다른 열 유형과 대조됩니다.
11.4.4. ENUM 유형
ENUM은 열 사양에 명시적으로 열거된 값의 열에서 값이 나오는 문자열 개체입니다. 테이블이 생성됩니다.
· ENUM에 잘못된 값(즉, 허용되는 값 열)을 삽입하는 경우 string)에는 특수 오류 값으로 빈 문자열이 삽입됩니다. 이 문자열은 나중에 자세히 설명하는 "일반적인" 빈 문자열과 다릅니다. ENUM 열이 NULL을 허용하도록 선언되면 NULL 값이 유효한 값입니다. ENUM 열이 NOT NULL로 선언된 경우 기본값은 허용되는 값 열의 첫 번째 요소입니다. 🎜>
· 열의 값은
열에 지정된 허용 값부터 1부터 시작하여 번호가 매겨집니다. · 빈 문자열 오류 값은 인덱스 값이 0입니다. 이는 다음 SELECT를 사용할 수 있음을 의미합니다. 잘못된 ENUM 값이 할당된 행을 찾는 명령문:
· NULL 값의 인덱스는
입니다. ENUM('1', '2', '3')으로 정의된 열은 아래에 표시된 모든 값을 가질 수 있습니다. 각 값의 인덱스도 표시됩니다.
값 인덱스
"0
'하나' 1
'둘' 2
'셋' 3
열거형에는 최대 65,535개의 요소가 포함될 수 있습니다.
테이블 생성 시 ENUM 멤버 값의 후행 공백이 자동으로 제거됩니다.
검색 시 ENUM 컬럼에 저장된 값은 컬럼 정의에 사용된 대소문자를 사용하여 표시됩니다. ENUM 열에는 문자 집합과 대조 규칙이 할당될 수 있습니다. 이진 또는 대소문자 구분 대조 규칙의 경우 열에 값을 할당할 때 대소문자를 고려해야 합니다.
숫자 컨텍스트에서 ENUM 값을 검색하는 경우 열 값의 인덱스가 반환됩니다. 예를 들어 다음과 같이 ENUM 열에서 숫자 값을 검색할 수 있습니다.
ENUM 열에 숫자를 저장하면 해당 숫자가 처리됩니다. 인덱스로 사용되며 저장된 값은 이 인덱스에 해당하는 열거형 멤버입니다. (단, 모든 입력을 문자열로 처리하는 LOAD DATA에서는 작동하지 않습니다.) 숫자와 유사한 열거형 값을 사용하여 ENUM 열을 정의하는 것은 권장되지 않습니다. 이는 쉽게 혼란을 초래할 수 있기 때문입니다. 예를 들어 다음 열에는 문자열 값이 '0', '1', '2'인 열거형 멤버가 포함되어 있지만 숫자 인덱스 값은 1, 2, 3입니다.
열 정의에 열거형 멤버가 나열된 순서에 따라 ENUM 값을 정렬합니다. (즉, ENUM 값은 인덱스 번호에 따라 정렬됩니다.) 예를 들어, ENUM('a', 'b')의 경우 'a'는 'b' 앞에 오고, ENUM('b', 'a')의 경우 'b'는 'a' 앞에 옵니다. 빈 문자열은 비어 있지 않은 문자열보다 먼저 정렬되고, NULL 값은 다른 모든 열거형 값보다 먼저 정렬됩니다. 예상치 못한 결과를 방지하려면 ENUM 열을 알파벳순으로 지정하세요. GROUP BY CAST(col AS CHAR) 또는 GROUP BY CONCAT(col)을 사용하여 열이 숫자순이 아닌 어휘순으로 정렬되도록 할 수도 있습니다.
ENUM 열에 가능한 모든 값을 확인하려면 SHOW COLUMNS FROM tbl_name LIKE enum_col을 사용하고 출력에서 열 2에 대한 ENUM 정의를 구문 분석하세요.
11.4.5.SET 유형
SET은 0개 이상의 값을 가질 수 있는 문자열 객체이며 해당 값은 테이블이 값으로 생성되었습니다. 여러 SET 멤버를 포함하는 SET 열 값을 지정하는 경우 쉼표(',')를 사용하여 각 멤버를 구분합니다. 이런 방식으로 SET 멤버 값 자체에는 쉼표가 포함될 수 없습니다.
예를 들어 SET('one', 'two') NOT NULL로 지정된 열은 다음 값 중 하나를 가질 수 있습니다.
SET 최대 64개의 서로 다른 멤버가 있을 수 있습니다.
테이블 생성 시 SET 멤버 값의 후행 공백이 자동으로 제거됩니다.
검색 시 SET 컬럼에 저장된 값이 컬럼 정의에 사용된 대소문자를 사용하여 표시됩니다. SET 열에는 문자 집합 및 조합 규칙을 할당할 수 있습니다. 이진 또는 대소문자 구분 대조 규칙의 경우 열에 값을 할당할 때 대소문자를 고려해야 합니다.
MySQL은 SET 값을 숫자로 저장하며, 저장된 값의 하위 비트는 첫 번째 SET 멤버에 해당합니다. SET 값이 숫자 컨텍스트에서 검색되는 경우 검색된 값의 비트 설정은 열 값을 구성하는 SET 멤버에 해당합니다. 예를 들어 다음과 같이 SET 열에서 숫자 값을 검색할 수 있습니다.
SET 열에 숫자를 저장하면 숫자의 이진 표현은 열 값의 SET 멤버로 결정됩니다. SET('a','b','c','d')로 지정된 열의 경우 멤버에는 다음과 같은 10진수 및 2진수 값이 있습니다.
SET 멤버 10진수 값 2진수 값
'a' 1 0001
'b' 2 0010
'c' 4 0100
열에 값 9가 할당됩니다. form은 1001이므로 1번째와 4번째 SET 값 멤버인 'a'와 'd'가 선택되어 결과 값은 'a,d'가 됩니다.
여러 SET 요소가 포함된 값의 경우 값을 삽입할 때 요소가 나열되는 순서는 중요하지 않습니다. 주어진 요소가 값에 몇 번 나열되는지는 중요하지 않습니다. 나중에 값을 검색하면 값의 각 요소가 한 번 나타나며 테이블을 만들 때 지정한 순서대로 요소가 나열됩니다. 예를 들어, 열이 SET('a','b','c','d')로 지정되었다고 가정하면:
' 값을 삽입하세요. a, d', 'd,a', 'a,d,d', 'a,d,a' 및 'd,a,d':
검색 시 이러한 값은 모두 'a,d'로 표시됩니다.
SET 열이 지원되지 않는 값으로 설정된 경우 해당 값은 무시하고 경고합니다:
SET 값은 숫자순으로 정렬됩니다. NULL 값은 NULL이 아닌 SET 값보다 먼저 정렬됩니다.
일반적으로 FIND_IN_SET() 함수 또는 LIKE 연산자를 사용하여 SET 값을 검색할 수 있습니다.
첫 번째 문에서는 SET_col이 값 세트 멤버 행을 포함합니다. 두 번째는 유사하지만 다릅니다. 즉, 다른 SET 멤버의 하위 문자열에서도 set_col에 값이 포함된 행을 찾습니다.
다음 문도 유효합니다.
첫 번째 문은 첫 번째 집합 멤버가 포함된 값을 찾습니다. 두 번째 문은 정확히 일치하는 값을 찾습니다. 카테고리 2 비교에 주의를 기울여야 합니다. 설정값을 'val1, val2'와 비교하여 반환되는 결과는 설정값을 'val2, val1'과 비교하여 반환되는 결과와 다릅니다. 값은 열 정의에 나열된 것과 동일한 순서로 지정되어야 합니다.
SET 열에 가능한 모든 값을 확인하려면 SHOW COLUMNS FROM tbl_name LIKE set_col을 사용하고 출력에서 열 2에 대한 SET 정의를 구문 분석하세요.
11.5. 열 유형 저장 요구 사항
MySQL이 지원하는 각 열 유형의 저장 요구 사항을 카테고리별로 나열합니다.
MyISAM 테이블의 최대 행 크기는 65,534바이트입니다. 각 BLOB 및 TEXT 열은 5~9바이트만 차지합니다.
MyISAM 테이블에 가변 길이 열 유형이 포함된 경우 레코드 형식도 가변 길이입니다. 테이블을 생성할 때 MySQL은 특정 조건에서 열을 가변 길이 유형에서 고정 길이 유형으로 또는 그 반대로 변경할 수 있습니다. 자세한 내용은 섹션 13.1.5.1, "자동 열 사양 변경"을 참조하세요.
숫자 유형 저장 요구 사항
열 유형 저장 요구 사항
TINYINT 1바이트
SMALLINT 2바이트
MEDIUMINT 3바이트
INT, INTEGER 4바이트
BIGINT 8바이트
FLOAT(p) if 0 <= p <= 24는 4바이트, if 25 <= p <= 53은 8바이트
FLOAT 4바이트
DOUBLE [PRECISION], 항목 REAL 8바이트
DECIMAL(M,D), NUMERIC(M,D) 가변 길이, 아래 설명 참조
BIT(M) 정보 (M+7)/8바이트
DECIMAL(및 NUMERIC)의 저장 요구 사항은 버전에 따라 다릅니다.
이진 형식을 사용하여 10진수 9자리(10 기준) 숫자를 4바이트로 압축하여 DECIMAL 열 값을 나타냅니다. 각 값의 정수 부분과 소수 부분의 저장은 별도로 결정됩니다. 9자리의 배수마다 4바이트가 필요하고 "나머지" 비트에는 4바이트의 일부가 필요합니다. 다음 표에는 초과 비트에 대한 저장 요구 사항이 나와 있습니다.
남은 바이트
비트 수
0 0
1 1
2 1
3 2
4 2
5 3
6 3
7 4
8 4
9 4
날짜 및 시간 유형에 대한 저장 요구사항
열 유형 저장 요구사항
DATE 3단어 섹션
DATETIME 8바이트
TIMESTAMP 4바이트
TIME 3바이트
YEAR 1바이트
문자열 유형 저장 요구 사항
열 유형 저장 요구 사항
CHAR(M) M 바이트, 0 <= M <= 255
VARCHAR(M) L+1 바이트, 여기서 L <= M 및 0
BINARY(M) M 바이트, 0
VARBINARY(M) L+1 바이트, 여기서 L
TINYBLOB, TINYTEXT L +1바이트, 여기서 L
BLOB, TEXT L+2바이트 , 여기서 L < 216
MEDIUMBLOB, MEDIUMTEXT L+3바이트, 여기서 L < 224
LONGBLOB, LONGTEXT L+4바이트, 여기서 L < ENUM('value1','value2',…) 1 또는 2바이트, 열거 값 수에 따라 (최대 65,535개 값)
SET('value1','value2',… ) 세트 구성원 수에 따라 1, 2, 3, 4 또는 8바이트(최대 64개 구성원)
VARCHAR, BLOB 및 TEXT 클래스는 가변 길이 유형입니다. 각 유형의 스토리지 요구사항은 유형의 가능한 최대 크기가 아니라 열 값의 실제 길이(이전 표에서 L로 표시됨)에 따라 달라집니다. 예를 들어, VARCHAR(10) 열은 최대 길이 10의 문자열을 보유할 수 있습니다. 실제 저장 요구 사항은 문자열 길이(L)에 문자열 길이를 기록하는 바이트를 더한 것입니다. 문자열 'abcd'의 경우 L은 4이고 저장에는 5바이트가 필요합니다.
CHAR, VARCHAR, TEXT 유형의 경우 위 표의 L 및 M 값은 문자 수로 해석되어야 하며, 열 정의에서 이러한 유형의 길이는 문자 수를 나타냅니다. 예를 들어 TINYTEXT 값을 저장하려면 L 문자 +
1바이트가 필요합니다.
특정 CHAR, VARCHAR 또는 TEXT 열의 값을 저장하는 데 사용되는 바이트 수를 계산하려면 해당 열에서 사용되는 문자 집합을 고려해야 합니다. 특정한 경우, 유니코드로 작업할 때 모든 유니코드 문자가 동일한 바이트 수를 사용한다는 점을 기억해야 합니다. 다양한 유니코드 문자 클래스에서 사용되는 저장소에 대한 분석은 섹션 10.5, “유니코드 지원”을 참조하세요.
참고: VARCHAR 열의 유효 최대 길이는 65,532자입니다.
NDBCLUSTER 엔진은 고정 너비 열만 지원합니다. 이는 MySQL Cluster 테이블의 VARCHAR 열이 CHAR 유형처럼 동작한다는 것을 의미합니다(각 레코드에 여전히 추가 바이트 공간이 있다는 점만 제외). 예를 들어 클러스터 테이블에서 VARCHAR(100)으로 선언된 열의 각 레코드는 실제 저장된 레코드의 문자열 길이에 관계없이 저장 시 101바이트를 차지합니다.
BLOB 및 TEXT 클래스는 클래스의 가능한 최대 길이에 따라 열 값의 길이를 기록하기 위해 1, 2, 3 또는 4바이트가 필요합니다. 섹션 11.4.3, “BLOB 및 TEXT 유형
”을 참조하세요.
NDB 클러스터 스토리지 엔진에서는 TEXT 및 BLOB 열의 구현이 다르며, 여기서 TEXT 열의 각 레코드는 두 개의 개별 부분으로 구성됩니다. 하나는 고정된 크기(256바이트)이며 실제로 원본 테이블에 저장됩니다. 다른 하나는 암시적 테이블에 보관된 256바이트를 초과하는 모든 데이터를 포함합니다. 두 번째 테이블의 레코드 길이는 항상 2,000바이트입니다. 즉, size+size+(2000–(size–256)%2000)입니다. .
ENUM 객체의 크기는 다양한 열거형 값의 수에 따라 결정됩니다. 열거형은 1바이트를 사용하며 255개의 가능한 값을 가질 수 있습니다. 열거형 값이 256에서 65,535 사이이면 2바이트가 사용됩니다. 섹션 11.4.4, “ENUM 유형”을 참조하십시오.
SET 개체의 크기는 다양한 집합 구성원의 수에 따라 결정됩니다. 설정된 크기가 N이면 개체는 (N+7)/8바이트를 차지하며 1, 2, 3, 4 또는 8바이트로 반올림됩니다. SET에는 최대 64명의 구성원이 포함될 수 있습니다. 섹션 11.4.5, “SET 유형”을 참조하십시오.
11.6. 올바른 열 유형 선택
저장을 최적화하려면 어떤 경우에도 가장 정확한 유형을 사용해야 합니다. 예를 들어 컬럼 값이 1부터 99999까지인 경우 정수를 사용한다면 MEDIUMINT
UNSIGNED가 좋은 타입이다. 이 유형은 열 값을 나타낼 수 있는 모든 유형 중 최소한의 저장 공간을 사용합니다.
10을 기준으로 65자리 정밀도의 십진수를 사용하여 DECIMAL 열에 대한 모든 기본 계산(+, -, *, /)을 수행합니다. 섹션 11.1.1, “숫자 유형 개요”를 참조하세요.
DECIMAL 값을 계산하려면 배정밀도 연산을 사용하세요. 정확도가 그다지 중요하지 않거나 속도가 가장 중요하다면 DOUBLE 유형이면 충분합니다. 높은 정밀도를 달성하기 위해 BIGINT에 저장된 고정 소수점 유형으로 변환을 수행할 수 있습니다. 이를 통해 모든 계산을 64비트 정수로 수행하고 필요에 따라 결과를 다시 부동 소수점 값으로 변환할 수 있습니다.
11.7. 다른 데이터베이스 엔진의 컬럼 유형 사용
다른 벤더에서 작성한 SQL 실행 코드를 사용하기 위해 MySQL은 다음 표와 같이 컬럼 유형을 매핑합니다. 테이블 정의는 다음 매핑을 통해 다른 데이터베이스 엔진에서 MySQL로 쉽게 가져올 수 있습니다.
다른 판매자 유형 MySQL 유형
BOOL, TINYINT
BOOLEAN TINYINT
CHAR VARYING(M) VARCHAR(M)
DEC DECIMAL
FIXED DECIMAL
FLOAT4 FLOAT
FLOAT8 DOUBLE
INT1 TINYINT
INT2 SMALLINT
INT3 MEDIUMINT
INT4 INT
INT8 BIGINT
LONG VARBINARY MEDIUMBLOB
LONG VARCHAR MEDIUMTEXT
LONG MEDIUMTEXT
MIDDLEINT MEDIUMINT
NUMERIC DECIMAL
테이블 컬럼 생성 시 컬럼 타입을 매핑한 후 원래 타입 정의를 버립니다. 다른 공급업체의 유형을 사용하여 테이블을 생성한 다음 DESCRIBE tbl_name 문을 실행하면 MySQL은 동등한 MySQL 유형을 사용하여 테이블의 구조를 보고합니다.
위 내용은 MySQL 학습 시리즈 3: Data Types 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!