Нужно сделать дамп и конвертировать между Latin1 и UTF-8 в MySQL, если все существующие данные являются ASCII? - PullRequest
2 голосов
/ 25 января 2012

Мне нужно преобразовать приложение, чтобы только текстовые поля использовали UTF-8 для кодирования.Хорошо, если все остальное - Latin1, как сейчас.БД была создана давным-давно, задолго до того, как я сюда попал, и задолго до того, как у группы возникли какие-либо амбиции по интернационализации приложения ...

Первоначально я планировал раздавать схему и данные по отдельности, повторно проверять схемучтобы изменить определения текстового поля для использования UTF-8, повторно импортируйте схему, а затем данные.Я написал скрипт для этого, и он работал как положено.

Проблема заключалась в том, что этот процесс занимал много времени, когда я запускал его на старом снимке наших производственных данных (> 2 часа).Ввод-вывод, очевидно, является узким местом - большая часть того времени была в том, чтобы получать и выводить дампы.Конечно, это было на моей рабочей станции, а не на машине с большей мощностью, но я обеспокоен тем, что даже с более мощной машиной я не смогу преобразовать свою (намного большую) текущую производственную базу данных в пределах нашего окна еженедельного обслуживания, котороеЭто единственный раз, когда сайт может быть недоступен в течение длительного времени.

Тогда я понял, что, возможно, мне на самом деле не нужно использовать стратегию дампа и конвертации.Поскольку на нашем сайте в настоящее время есть только пользователи на английском языке, наши текстовые данные не содержат никаких специальных символов (кажется, даже символов с акцентом).Из-за совпадения между кодовыми точками Latin1 и Unicode, разве я не должен быть в порядке, просто ALTER TABLE в каждой таблице, чтобы изменить кодировки текстовых полей?Или есть какая-то другая проблема, из-за которой я все равно буду делать дамп-конвертирование?

1 Ответ

2 голосов
/ 25 января 2012

Я думаю, что лучший подход - изменить столбцы на тип BLOB, а затем изменить их обратно на TEXT или VARCHAR или еще много чего, например:

ALTER TABLE table_name MODIFY column_name BLOB;
ALTER TABLE table_name MODIFY column_name ~~~~~ CHARACTER SET utf8;

где ~~~~~ - это тип, который вы хотите, например, VARCHAR(20) (что, кстати, означает «20 символов», а, к счастью, не «20 байтов»).

Причина, по которой я предлагаю перейти по BLOB, заключается в том, что если вы только что сделали это:

ALTER TABLE table_name MODIFY column_name ~~~~~ CHARACTER SET utf8;

тогда MySQL будет пытаться обновить каждую запись, чтобы преобразовать ее из Latin-1 в UTF-8 & mdash; что будет правильным, но ненужным и медленным. (Подход "сквозной-* 1015" - это , что документация рекомендует делать , когда ваш столбец определен как CHARACTER SET latin1, но ошибочно содержит данные UTF-8, чтобы избежать ошибочного преобразования. в вашем случае преобразование не является ошибочным, но все равно не требуется.)

Вероятно, также лучше заранее отбросить любые индексы и затем заново их создать.

Важный отказ от ответственности: Вы должны проверить вышеупомянутое предположение, используя старый снимок, который вы упомянули. Возможно, что переключение на BLOB и обратно также будет медленным и дорогостоящим, и в этом случае я полагаю, что вам лучше просто выполнить одиночное преобразование. Я думаю, что это будет зависеть от механизма хранения.

Кстати, мне было бы интересно услышать результаты вашего теста. : -)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...