MySQL5.6 YEAR (2)의 제한 및 YEAR (4)로 전환

11.3.4 YEAR (2)의 제한 및 YEAR (4)로 전환

이 섹션에서는 YEAR(2) 를 사용할 때 발생할 수있는 문제를 거론 기존 YEAR(2) 컬럼을 YEAR(4) 로 변환하기위한 정보를 제공합니다.

YEAR(4) 와 YEAR(2) 의 값의 내부 범위는 같지만 ( 1901 에서 2155 및 0000 ), YEAR(2) 의 표시 폭은 표시 값이 내부 값의 마지막 두 자리 만 표시하고, 세기를 나타내는 최초의 2 자리를 생략하기 때문에 그 형태가 모호합니다. 특정 상황에서 정보가 손실되는 결과가 될 수도 있습니다. 따라서 YEAR 데이터 형식이 필요할 때마다 응용 프로그램 전체에서 YEAR(2) 의 사용을 피하고 YEAR(4) 를 사용하도록 고려하십시오. MySQL 5.6.6 이후에서는 4 이외의 표시 값 YEAR 데이터 형 (특히 YEAR(2) )의 지원을 축소하고 향후 릴리스에서 완전히 제거 될 예정이므로, 어느 시점 변환이 필요합니다 .

YEAR (2) 제한

YEAR(2) 데이터 형 문제는 표시 값의 모호성과 가치 덤프 및 리로드시 또는 문자열로 변환 할 때 정보 손실의 가능성이 있습니다.

YEAR(2) 의 표시 값은 모호한 경우가 있습니다. 다음의 예와 같이 다른 내부 값을 가진 최대 3 개의 YEAR(2) 값을 같은 표시 값으로 할 수 있습니다.

mysql> CREATE TABLE t (y2 YEAR(2), y4 YEAR(4));
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO t (y2) VALUES(1912),(2012),(2112);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> UPDATE t SET y4 = y2;
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0

mysql> SELECT * FROM t;
+------+------+
| y2   | y4   |
+------+------+
|   12 | 1912 |
|   12 | 2012 |
|   12 | 2112 |
+------+------+
3 rows in set (0.00 sec)

mysqldump를 사용하여 위의 항목에 작성된 테이블을 덤프하는 경우 덤프 파일은 같은 2 자리 표현 ( 12 )를 사용하여 모든 y2 값을 나타냅니다. 덤프 파일에서 테이블을 다시로드하면 모든 결과 행 내부 값 2012 과 표시 값 12 를 포함되기 때문에 이러한 차이가 없어집니다.
YEAR(2) 또는 YEAR(4) 데이터 값을 문자열 표현으로 변환하는 경우 YEAR 형의 표시 폭이 사용됩니다. YEAR(2) 와 YEAR(4) 의 두 컬럼에 1970 값이 포함된다고합니다. 각각의 컬럼을 문자열에 할당 한 결과 각각 '70' 과 '1970' 의 값이됩니다. 즉, YEAR(2) 에서 문자열로 변환 할 정보의 손실이 발생합니다.
1970 에서 2069 의 범위에서 벗어난 값은 CSV 테이블 YEAR(2) 컬럼에 삽입 될 때 잘못 저장됩니다. 예를 들어, 2111 을 삽입하면 표시 값은 11 입니다 만, 내부 값은 2011 입니다.

이러한 문제를 방지하려면 YEAR(2) 대신 YEAR(4) 를 사용하십시오. 마이그레이션 전략에 관한 제안은이 섹션 뒷부분합니다.

MySQL 5.6의 YEAR (2) 지원의 축소

MySQL 5.6.6 이후로 YEAR(2) 의 지원은 축소됩니다.

새 테이블 YEAR(2) 컬럼 정의는 YEAR(4) 에 (경고와 함께) 변환됩니다.

 mysql> CREATE TABLE t1 (y YEAR(2));
 Query OK, 0 rows affected 1 warning (0.03 sec)

 mysql> SHOW WARNINGS\G
 *************************** 1. row ******************** *******
   Level : Warning
    Code : 1818
 Message : YEAR (2) column type is deprecated. Creating YEAR (4) column instead.
 1 row in set (0.00 sec)

 mysql> SHOW CREATE TABLE t1\G
 *************************** 1. row ******************** *******
        Table : t1
 Create Table : CREATE TABLE`t1` (
   `y` year (4) DEFAULT NULL
 ) ENGINE = InnoDB DEFAULT CHARSET = latin1
 1 row in set (0.00 sec)

기존 테이블 YEAR(2) 는 YEAR(2) 로 남아 이전 버전의 MySQL과 마찬가지로 쿼리에서 처리됩니다. 그러나 여러 프로그램 또는 문이 YEAR(2) 를 YEAR(4) 로 자동 변환합니다.
- 테이블 재구성을 초래 ALTER TABLE 문.
- REPAIR TABLE ( YEAR(2) 컬럼이 테이블에 포함될 수 CHECK TABLE 에서 감지 된 경우에 사용하도록 권장됩니다).
- mysql_upgrade ( REPAIR TABLE 을 사용합니다).
- mysqldump로 덤프 및 덤프 파일 다시로드합니다. 위의 3 가지 항목이 수행하는 변환과는 달리, 덤프 및 리로드 값을 변경할 수 있습니다.
MySQL 업그레이드는 일반적으로 마지막 두 항목 중 적어도 하나를 포함합니다. 그러나 YEAR(2) 에 대해서는 mysql_upgrade를 권장합니다. 전술 한 바와 같이 값을 변경할 수 있으므로, mysqldump는 사용하지 마십시오.

YEAR (2)에서 YEAR (4)로 전환

YEAR(2) 컬럼을 YEAR(4) 로 변환하려면 수동으로 업그레이드없이 언제든지 가능합니다. 또는 YEAR(2) 의 지원이 축소 된 버전의 MySQL (MySQL 5.6.6 이후)으로 업그레이드 한 후 MySQL에서 YEAR(2) 컬럼을 자동으로 변환 할 수 있습니다. 후자의 경우는 데이터의 덤프 및 리로드에 의한 업그레이드하지 마십시오. 데이터 값을 변경할 수 있습니다. 또한 복제를 사용하는 경우는주의를 요하는 업그레이드 고려 사항이 있습니다.

YEAR(2) 컬럼을 YEAR(4) 수동으로 변환하려면 ALTER TABLE 을 사용하십시오. 테이블 t1 에 다음의 정의가 있다고합니다.

 CREATE TABLE t1 (ycol YEAR (2) NOT NULL DEFAULT '70');

다음과 같이 ALTER TABLE 을 사용하여 열을 변경합니다. 반드시 NOT NULL 과 DEFAULT 등의 모든 컬럼 속성을 포함해야합니다.

 ALTER TABLE t1 MODIFY ycol YEAR (4) NOT NULL DEFAULT '1970';

ALTER TABLE 문은 YEAR(2) 값을 변경하지 않고 테이블을 변환합니다. 서버가 복제 마스터 인 경우, ALTER TABLE 문은 슬레이브에 복제 된 각 대응하는 테이블을 변경합니다.

다른 이동 방법은 바이너리 업그레이드를 실행합니다. 데이터 덤프 및 리로드하지 않고 MySQL 5.6.6 이상을 설치합니다. 이어 mysql_upgrade를 실행합니다. 이것은 REPAIR TABLE 을 사용하여 데이터 값을 변경하지 YEAR(2) 컬럼을 YEAR(4) 로 변환합니다. 서버가 복제 마스터 인 경우, --skip-write-binlog 옵션으로 mysql_upgrade를 호출하지 않는 한, REPAIR TABLE 문은 슬레이브에 복제 된 각 대응하는 테이블을 변경합니다.

복제 서버로 업그레이드는 일반적으로 새로운 버전의 MySQL의 노예 업그레이드와 마스터의 업그레이드가 이루어집니다. 예를 들어, 마스터와 슬레이브에 MySQL 5.5를 실행하는 경우, 통상의 업그레이드 순서는 슬레이브을 5.6로 업그레이드 한 후 마스터를 5.6로 업그레이드합니다. MySQL 5.6.6 이상에서 YEAR(2) 다른 취급에 관해서는이 업그레이드 순서에 따라 문제가 발생합니다. 슬레이브가 업그레이드되어 있지만, 주인이 아직 업그레이드되지 않는다고합니다. 이 경우 마스터에 YEAR(2) 컬럼을 포함한 테이블을 작성하면 슬레이브에서는 YEAR(4) 컬럼을 포함하는 테이블이 생성됩니다. 따라서 문 기반 복제를 사용하면 이러한 작업은 마스터와 슬레이브로 다른 결과입니다.

숫자 0 의 삽입. 결과 값은 마스터에서는 2000 의 내부 값되지만 슬레이브에서는 0000 의 내부 값입니다.
문자열에 YEAR(2) 의 변환. 이 작업은 마스터에서는 YEAR(2) 의 표시 값을 사용하지만, 슬레이브에서는 YEAR(4) 의 표시 값을 사용합니다.

이러한 문제를 피하려면 다음 전략 중 하나를 사용합니다.

문 기반 복제 대신 행 기반 복제를 사용합니다.
업그레이드 전에 마스터의 모든 YEAR(2) 컬럼을 YEAR(4) 로 변경합니다. (전술 한 바와 같이 ALTER TABLE 을 사용합니다.) 이어 YEAR(2) 에서 YEAR(4) 마이그레이션 마스터와 슬레이브간에 차이가 발생하지 않고 정상적으로 (먼저 슬레이브 다음 마스터 ) 업그레이드 할 수 있습니다).

mysqldump로 데이터를 덤프하고 업그레이드 한 후에 덤프 파일을 다시로드하는 전환 방법은 사용하지 마십시오. 전술 한 바와 같이, 이것은 YEAR(2) 값을 변경할 수 있습니다.

YEAR(2) 에서 YEAR(4) 로 전환에서는 다음과 같은 조건에서 동작이 변경되었을 가능성이 있는지 응용 프로그램 코드의 검사도해야합니다.

YEAR 컬럼을 선택하면 정확히 2 자리가 생성 될 것으로 예상하고있다 코드.
0 을 YEAR(2) 또는 YEAR(4) 에 삽입하면 각각 2000 또는 0000 의 내부 값이된다는 숫자 0 의 삽입에 대한 별도의 처리에 대응하지 않는 코드.