2015-04-20 2 views
1

Я получаю синтаксическую ошибку при попытке загрузить файл mysqldump.sql-ошибка при загрузке файла mysqldump

Мой вопрос имеет несколько частей:

(1) Почему MySQL не может правильно прочитать файл, который MySQLDump выход?
(2) Как я могу заставить mysql читать в соответствующих данных из файла?

Heres некоторые детали:

mysqldump -u username -p dbname > mydumpfile.sql идет хорошо (по-видимому)

mysql -u testuser -p testdbname < mydumpfile.sql получает только через часть (около 1/3) файла, а затем дает ошибку синтаксиса:

ERROR 1064 (42000) at line 249: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'randomimproperlydisplayingjapanesetext',''),(508715,134707' at line 1

Текст, показанный как синтаксическая ошибка, вскоре после начала нового оператора insert.

Оператор заявления (большой) вставки в предыдущей строке не вводится в базу данных.

Данные взяты из базы данных с японским текстом, а в столбце имеется команда utf8_general_ci.

Версия MySQL 5.6.23 на окнах xp.

Вот другие соответствующие переменные (я думаю):

mysql> show variables like '%char%'; 
+--------------------------+------------------------------+ 
| Variable_name   | Value      | 
+--------------------------+------------------------------+ 
| character_set_client  | sjis       | 
| character_set_connection | sjis       | 
| character_set_database | sjis       | 
| character_set_filesystem | binary      | 
| character_set_results | sjis       | 
| character_set_server  | sjis       | 
| character_set_system  | utf8       | 
| character_sets_dir  | C:\mysql\share\charsets\  | 
+--------------------------+------------------------------+ 

Edit на основе ниже ответа, я решил, что былSET NAMES линия в туздЫшпр для установки его в качестве utf8.

Вот это SHOW CREATE TABLE trouble_table Результаты:

CREATE TABLE `trouble_table` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `version_id` int(11) DEFAULT NULL, 
    `myutf8column` varchar(100) CHARACTER SET utf8 DEFAULT NULL, 
    `mysjisenumcolumn` enum('一式','*',[a few other japanese charactes]) CHARACTER SET sjis DEFAULT NULL, 
    PRIMARY KEY (`id`), 
    KEY `version_id` (`version_id`) 
) ENGINE=InnoDB AUTO_INCREMENT=946033 DEFAULT CHARSET=utf16 ` 

Таким образом, таблица набора символов utf16 (я забыл, почему), один utf8 столбец и один столбец SJIS. В файле msyqldump я могу прочитать все значения, хотя кажется, что в файле дампа все кодируются одинаково.

SELECT HEX(mytuf8column), похоже, подтверждает, что myutf8column имеет кодировку utf8 (начинается с кодов, упомянутых ниже, то есть E383xx, Ewxxyy), а mysjiscolumn имеет шестнадцатеричные значения, начиная с 95, поэтому я предполагаю, что это, вероятно, sjis.

Кроме того, после чтения this SOV question, я проверил и установил max_allowed_packet как 33554432, а не по умолчанию, но это не изменило проблему.

Часть таблицы, которая загружается, не имеет заметных проблем со вставленными данными, но для меня слишком много данных, чтобы действительно просмотреть данные db или файл mysqldump и заметить любые «странные» символы, которые могут быть заставляя mysql задыхаться. (Файл mysqldump превышает 50 Мбайт, поэтому он не огромен по стандарту db, но достаточно большой, чтобы быть очень трудным для чтения, Notepad ++ и emacs кажутся беспомощными)

Еще одна вещь, я нервничаю из-за изменения сортировки столбцов, потому что я не хотите потерять какие-либо данные (если текущая кодировка неверна, безопасно ли ее изменить на другую кодировку?). Потребовалось много времени для анализа в исходных данных, поэтому я пытаюсь сделать резервную копию.Редактировать Основываясь на ответе ниже, я больше не нервничаю из-за изменения сортировки, потому что это всего лишь правило для сравнения, скорее я нервничаю из-за изменения наборов символов.

Кстати, это не имеет большого значения, если mysql нужно просто пропустить несколько проблемных строк.

+0

«кажется, что в файле дампа все кодируются одинаково». Вы имеете в виду, что некоторые выглядят правильно закодированными в sjis, некоторые в utf8? –

+0

Возвращаясь к ошибке, вы можете найти символы перед «" randomimproperlydisplayingjapanesetext ", ''), (508715,134707 '"? Вот в чем проблема. Или, возможно, экранирование в этом тексте загрязнено (sjis), вероятно, имеет «» как один байт допустимого символа. Это может указывать на ошибку в mysqldump при демпинге sjis. –

+0

@RickJames, (1) в отношении вашего вопроса о кодировке, я имею в виду, что в основном все символы в файле mysqldump являются разборчивыми , и поэтому закодирован таким же образом * в * файле mysqldump (извините, возможно, это очевидно).(2) Текст перед ошибкой «INSERT INTO» troubletable »VALUES (x, x, x, x, x), (508715,134707 '', но я думаю, что проблема заключается в строке * перед * оператор ошибки, то есть где-то внутри оператора INSERT для 15000 строк.Эти записи не вставляются в БД. Сейчас я удаляю 1000 записей за раз, чтобы найти ошибки. – user4652310

ответ

0

sjis и utf8_general_ci не связаны. Хотя можно использовать sjis в клиенте и utf8 в таблицах, это кажется ненужной смесью.

sjis и utf8 являются «УСТАНОВКИ ХАРАКТЕРА».
sjis_japanese_ci и utf8_general_ci соответствуют «СОБРАНИЯМ».
Проблема в том, что касается ХАРАКТЕРОВ.

Проверьте байты (или источник) японских символов, которые вы пытаетесь вставить, - проверьте, являются ли они 2-байтовыми sjis-кодировками или 3-байтными кодировками utf8.

шестигранной для японского языка в utf8:

  • E381yy - хираган
  • E383yy - катакан
  • Ewxxyy - кандзи

шестигранные для SJIS практически любая комбинация, так трудно «распознать».

Аналогично проверьте данные в таблицах с SELECT col, HEX(col) .... Также сделайте (и укажите для нас) SHOW CREATE TABLE для одной из таблиц.

Вернуться к проблеме ...

mysqldump При использовании, вы имели --set-charset (и не --skip-set-charset)? Если это так, в файле дампа должно быть SET NAMES. Проверьте это. Он должен быть рядом с вершиной. Если он есть, нам нужно копать дальше, чтобы понять, что происходит не так.

Если его там нет, вы можете компенсировать его отсутствие. В заявлении mysql используйте --default-character-set=xx, где xx либо sjis, либо utf8, в зависимости от того, какое кодирование находится в дампе.

Если этих ключей недостаточно, пожалуйста, отредактируйте свой вопрос с ответами на поставленные мной вопросы.

+0

Приветствия за подсказки, я в гораздо лучшем положении для устранения неполадок, но пока не повезло. Я отредактировал свой вопрос, чтобы включить дополнительные сведения о 'SET NAMES', а также подробные сведения о символах таблицы и столбца. – user4652310

+0

Этот ответ в основном прав, но просто для того, чтобы подчеркнуть: набор символов для mysqldump должен быть сопоставлен с набором символов для ввода mysql. Если набор параметров по умолчанию установлен в файле конфигурации mysql в параметре [mysql], я рекомендую установить ту же опцию в разделе [mysqldump], чтобы избежать таких проблем. Все еще не уверен, почему полмиллиона записей загружены без проблем, хотя .. – user4652310

1

В моем случае это было вызвано разницей версий между экспортирующими и импортирующими версиями mysql. Мой экспорт mysql был 5.7.x (Ubuntu 16.04), но импорт был 5.5.x (Ubuntu 14.04). После обновления импорта до 5.7.x на following this guide он работал.

Смежные вопросы