Я получаю синтаксическую ошибку при попытке загрузить файл 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 нужно просто пропустить несколько проблемных строк.
«кажется, что в файле дампа все кодируются одинаково». Вы имеете в виду, что некоторые выглядят правильно закодированными в sjis, некоторые в utf8? –
Возвращаясь к ошибке, вы можете найти символы перед «" randomimproperlydisplayingjapanesetext ", ''), (508715,134707 '"? Вот в чем проблема. Или, возможно, экранирование в этом тексте загрязнено (sjis), вероятно, имеет «» как один байт допустимого символа. Это может указывать на ошибку в mysqldump при демпинге sjis. –
@RickJames, (1) в отношении вашего вопроса о кодировке, я имею в виду, что в основном все символы в файле mysqldump являются разборчивыми , и поэтому закодирован таким же образом * в * файле mysqldump (извините, возможно, это очевидно).(2) Текст перед ошибкой «INSERT INTO» troubletable »VALUES (x, x, x, x, x), (508715,134707 '', но я думаю, что проблема заключается в строке * перед * оператор ошибки, то есть где-то внутри оператора INSERT для 15000 строк.Эти записи не вставляются в БД. Сейчас я удаляю 1000 записей за раз, чтобы найти ошибки. – user4652310