I en mysql-databackup- og gjenopprettingsoperasjon oppsto et problem: etter å ha brukt sqlyog til databackup, og deretter gjenopprettet dataene på en annen server, ble "'"-separatoren slukt på grunn av varbinary-feltet i en av tabellene (på grunn av problemet med binær koding ble anførselstegnsseparatoren behandlet som en del av dataene), slik at dataene ikke kunne importeres normalt.
Noen tekstverktøy ble brukt til behandling, men de lyktes ikke, noen av dem kunne gjenkjennes, men endret automatisk de binærkodede dataene, og noen satte inn annen binær data, noe som resulterte i fortsatt uleselig.
Så vurder andre metoder: les dataene og stav SQL-setningen, og importer den deretter. De spesifikke metodene er:
(1) Bruk HEX-funksjonen for å lese dataene ved eksport, og konvertere de binære dataene til en heksadesimal streng;
velg HEX(binField) fra testTable;
(2) Bruk UNHEX-funksjonen for å konvertere heksadesimalstrengen til den binære dataimportdatabasen under importen;
sett inn i testTable binField-verdier(UNHEX(@hexstr));
Følgende kode demonstrerer funksjonaliteten til HEX og UNHEX:
SELECT HEX('this is a test str') og resultatet av spørringen er: 746869732069732061207465737420737472 VELG UNHEX('746869732069732061207465737420737472'), og resultatet av spørringen er: dette er en teststyrke
Du kan også lese heksadesimaltegnet direkte, og legge til et 0x-prefiks til strengen: SELECT 0x746869732069732061207465737420737472, spørringsresultatet er: dette er en teststyrke
I tillegg kan du også bruke binære import- og eksportmetoder for å sikkerhetskopiere og gjenopprette data. Det er ingen diskusjon her.
|