Під час операції резервного копіювання та відновлення даних mysql виникла проблема: після використання sqlyog для резервного копіювання даних, а потім відновлення даних на іншому сервері, роздільник «'» був поглинений через варбінарне поле в одній із таблиць (через проблему бінарного кодування роздільник лапок розглядався як частина даних), через що дані не можна було імпортувати нормально.
Деякі текстові інструменти використовувалися для обробки, але вони були безуспішними, деякі з них можна було розпізнати, але вони автоматично змінювали бінарні закодовані дані, а деякі вставляли інші бінарні дані, через що вони залишалися нечитабельними.
Тож розгляньте інші методи: прочитайте дані, напишіть SQL-оператор, а потім імпортуйте його. Конкретні методи такі:
(1) використовувати функцію HEX для зчитування даних під час експорту та конвертувати бінарні дані у шістнадцятковий рядок;
виберіть HEX(binField) з testTable;
(2) Використання функції UNHEX для конвертації шістнадцяткового рядка у базу даних імпорту бінарних даних під час імпорту;
вставити у testTable значення binField (UNHEX(@hexstr));
Наступний код демонструє функціональність HEX та UNHEX:
ВИБЕРІТЬ HEX('це тестова сила'), і результат запиту: 746869732069732061207465737420737472
SELECT UNHEX('746869732069732061207465737420737472'), і результат запиту: це тестова str
Ви також можете прочитати шістнадцятковий символ напряму, додаючи префікс 0x до рядка:
SELECT 0x746869732069732061207465737420737472, результат запиту: це тестова сила
Крім того, можна використовувати бінарні методи імпорту та експорту для резервного копіювання та відновлення даних. Тут немає жодної дискусії.
|
Опубліковано 13.06.2016 22:27:47
|
|
|
