Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Хотя внутренний диапазон значений для YEAR(4) и YEAR(2) то же самое (1901 к 2155,
и 0000), дисплей width для YEAR(2)
делает тот тип по сути неоднозначным, потому что выведенные на экран значения указывают только на последние две
цифры внутренних значений. Результатом может быть потеря информации при определенных обстоятельствах. Поэтому
рассмотрите уход от YEAR(2) всюду по Вашим приложениям и использованию YEAR(4) везде, где Вы нуждаетесь в a YEAR тип данных. Этот раздел описывает проблемы, которые могут произойти при
использовании YEAR(2)
и предоставляет информацию о переходе существующего YEAR(2)
столбцы к YEAR(4).
Отметьте, что миграция станет необходимой в некоторый момент потому что поддержка YEAR типы данных с дисплеем оценивают кроме 4, наиболее особенно YEAR(2), уменьшается с MySQL 5.6.6 и будет удален полностью в будущем
выпуске.
YEAR(2) Ограничения Проблемы с YEAR(2)
тип данных включает неоднозначность выведенных на экран значений, и возможную потерю информации, когда значения
выводятся и перезагружаются или преобразовываются в строки.
Выведенный на экран YEAR(2) значения могут быть неоднозначными. Это возможно для трех 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: 0mysql>UPDATE t SET y4 = y2;Query OK, 3 rows affected (0.00 sec)Rows matched: 3 Changed: 3 Warnings: 0mysql>SELECT * FROM t;+------+------+| y2 | y4 |+------+------+| 12 | 1912 || 12 | 2012 || 12 | 2112 |+------+------+3 rows in set (0.00 sec)
Если Вы используете mysqldump, чтобы вывести таблицу, составленную в
предыдущем элементе, файл дампа представляет все y2 значения используя то
же самое 2-разрядное представление (12). Если Вы перезагружаете таблицу от
файла дампа, у всех получающихся строк есть внутреннее значение 2012 и
значение дисплея 12, таким образом теряя различия среди них.
Преобразование a YEAR(2) или YEAR(4)
значение данных, чтобы представить форму в виде строки использует дисплей width YEAR ввести. Предположите это YEAR(2) и YEAR(4)
столбцы оба содержат значение 1970. Присвоение каждого столбца к строке
приводит к значению '70' или '1970',
соответственно. Таким образом, потеря информации происходит для преобразования из YEAR(2) представлять в виде строки.
Значения вне диапазона от 1970 к 2069 сохранены неправильно когда вставлено в a YEAR(2) столбец в a CSV таблица. Например, вставка 2111
результаты в значении дисплея 11 но внутреннее значение 2011.
Чтобы избежать этих проблем, использовать YEAR(4)
вместо YEAR(2). Предложения относительно стратегий миграции появляются позже в этом
разделе.
YEAR(2)
Поддержка в MySQL 5.6 С 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: 1818Message: 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: t1Create Table: CREATE TABLE `t1` ( `y` year(4) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=latin11 row in set (0.00 sec)
YEAR(2) в существующих таблицах остается как YEAR(2) и обрабатывается в запросах как в более старых версиях MySQL.
Однако, несколько программ или операторов преобразовывают YEAR(2) к YEAR(4)
автоматически:
ALTER
TABLE операторы, которые приводят к таблице, восстанавливают.
REPAIR
TABLE (который CHECK
TABLE рекомендует, чтобы Вы использовали, если это находит, что таблица содержит
YEAR(2) столбцы).
mysql_upgrade (который использует REPAIR TABLE).
Дамп с mysqldump и перезагрузка файла дампа. В отличие от преобразований, выполняемых предшествованием трем элементам, дампу и перезагрузке, имеет потенциал, чтобы изменить значения.
Обновление MySQL обычно включает по крайней мере один из последних двух элементов. Однако,
относительно YEAR(2), следует избежать выводить и перезагружать; как отмечено,
это может изменить значения.
YEAR(2) к YEAR(4) Если Вы решаете преобразовать YEAR(2) столбцы к YEAR(4), можно сделать так вручную в любое время без обновления. Альтернативно,
можно обновить до версии MySQL с уменьшенной поддержкой YEAR(2)
(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)
не изменяя значения данных. Если сервер является ведущим устройством репликации, REPAIR TABLE операторы тиражируются к ведомым устройствам и производят
соответствующие табличные изменения на каждом, если Вы не вызываете mysql_upgrade с --skip-write-binlog опция.
Обновления до серверов репликации обычно включают ведомые устройства обновления более новой версии MySQL, затем
обновляя ведущее устройство. Например, если ведущее устройство и ведомое устройство оба выполненных MySQL 5.5,
типичная последовательность обновления включает обновление ведомого устройства 5.6, то, обновляя ведущее
устройство до 5.6. Относительно другого отношения YEAR(2) с MySQL 5.6.6 та последовательность обновления приводит к проблеме:
Предположите, что ведомое устройство еще было обновлено, но ведущее устройство. Затем составляя таблицу,
содержащую a YEAR(2)
столбец на ведущем устройстве приводит к таблице, содержащей a YEAR(4) столбец на ведомом устройстве. Следовательно, у этих операций будет
различный результат на ведущем устройстве и ведомом устройстве, если Вы будете использовать основанную на
операторе репликацию:
Чтобы избежать таких проблем, используйте одну из этих стратегий:
Используйте построчную репликацию вместо основанной на операторе репликации.
Измените все YEAR(2)
столбцы на ведущем устройстве к YEAR(4) перед обновлением. (Используйте ALTER TABLE, как описано ранее.) Затем можно обычно обновлять
(ведомое устройство сначала, тогда ведущее устройство), не представляя никого YEAR(2) к YEAR(4)
различия между ведущим устройством и ведомым устройством).
Одного метода миграции нужно избежать: не выводите свои данные с mysqldump и перезагружайте файл дампа после обновления. У этого
есть потенциал, чтобы измениться YEAR(2) значения, как описано ранее.
Миграция от YEAR(2)
к YEAR(4)
должен также включить код программы исследования для возможности измененного поведения при условиях, таких как
они: