Является ли нормальным для оператора MySQL create table включение избыточных объявлений сопоставления для каждого столбца char, varchar и text? - PullRequest
Новая
       49

Является ли нормальным для оператора MySQL create table включение избыточных объявлений сопоставления для каждого столбца char, varchar и text?

1 голос
/ 21 февраля 2020

При запуске SHOW CREATE TABLE `my_table`; я замечаю, что COLLATE utf8mb4_unicode_ci отображается для каждого столбца char, varchar и text в таблице. Это кажется немного избыточным, поскольку параметры сортировки уже объявлены в части table_option оператора create. 

mysql> SHOW CREATE TABLE `my_table`;
| Table    | Create Table
| my_table | CREATE TABLE `my_table` (
...
  `char_col_1` char(15) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `varchar_col_1` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `varchar_col_2` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `varchar_col_3` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `text_col_1` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
...
) ENGINE=InnoDB AUTO_INCREMENT=1816178 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

Это поведение заметно как в MySQL 5.7, так и в MySQL 8.0. и, следовательно, скорее всего, и в других версиях.

Является ли это поведение нормальным и приемлемым, или это признак того, что что-то неправильно настроено либо для таблицы, базы данных, либо для экземпляра MySQL?

С другой стороны, поскольку параметры сортировки могут быть индивидуально установлены для любого определенного столбца c, возможно, лучше явно отображать параметры сортировки для каждого столбца, чтобы избежать двусмысленности или допущений даже в тех случаях, когда параметры сортировки столбца совпадают. сопоставление таблицы?

Ответы [ 2 ]

1 голос
/ 21 февраля 2020

Вы коснулись только вершины айсберга.

  • Я думаю, что настройки в таблице - это просто значения по умолчанию для столбцов, которые определены без набора символов или сопоставления.
  • То же самое для ALTER TABLE ADD COLUMN - будет наследовать от таблицы по умолчанию.
  • Я думаю, что настройки столбца помещаются в таблицу information_schema.COLUMNS, и это не изменится с ALTER TABLE .. MODIFY COLUMN ..

Аналогично, кодировка таблицы *1015* и параметры сортировки наследуются от определения database и будут заморожены при определении таблицы.

О значениях по умолчанию:

  • Старая кодировка по умолчанию была latin1
  • Текущее значение по умолчанию utf8mb4; вряд ли это когда-либо изменится в будущем.
  • Каждое сопоставление относится только к одной кодировке, а имя кодировки является началом имени сопоставления.
  • Каждый набор имеет ровно одно "значение по умолчанию" параметры сортировки: latin1_swedish_ci, utf8_unicode_ci, utf8mb4_0900_ai_ci и т. д. c.
  • Это сопоставление по умолчанию (для данной кодировки) редко, если вообще изменяется. Возможно, единственное изменение было для utf8mb4 между 5.7 и 8.0 ??

(Чем больше я экспериментирую, тем меньше я уверен в этом.)

Лучшая практика: всегда явно установите CHARSET и COLLATE для каждого строкового столбца.

Дополнительные соображения:

  • Используйте utf8mb4, если доступно, для большинства строк (VARCHAR / TEXT ).
  • Использовать последние доступные параметры сортировки (Unicode продолжает их улучшать); в настоящее время utf8mb4_0900_ai_ci.
  • Используйте ascii для вещей, которые явно только ascii - код страны, postal_code, hex и т. д. c. В основном они могут использовать CHAR(..)
  • Использовать ascii_general_ci или ascii_bin, в зависимости от того, нужно ли вам складывать футляр.
0 голосов
/ 21 февраля 2020

Да, избыточно иметь CHARACTER SET и COLLATION одинаковые в определении таблицы и определении столбца.

Наличие явных определений столбца означает, что любой может изменить определения таблицы на CHARACTER SET или COLLATION столбец останется идентичным.

...