LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name
.txt' [REPLACE | IGNORE] INTO TABLEtbl_name
[FIELDS [TERMINATED BY 'string
'] [[OPTIONALLY] ENCLOSED BY 'char
'] [ESCAPED BY 'char
' ] ] [LINES [STARTING BY 'string
'] [TERMINATED BY 'string
'] ] [IGNOREnumber
LINES] [(col_name_or_user_var
,...)] [SETcol_name
=expr
,...)]
El comando LOAD DATA INFILE
lee registros
desde un fichero de texto a una tabla a muy alta velocidad. El
nombre de fichero debe darse como una cadena literal.
Para más información acerca de la eficiencia de
INSERT
contra LOAD DATA
INFILE
y acelerar LOAD DATA INFILE
,
consulte Sección 7.2.14, “Velocidad de la sentencia INSERT
”.
En MySQL 5.0, el conjunto de caracteres indicado por la variable
de sistema character_set_database
se usa para
interpretar la información en el fichero. SET
NAMES
y el valor de
character_set_client
no afecta la
interpretación de la entrada.
Puede cargar ficheros de datos usando la utilidad
mysqlimport ; opera enviando un comando
LOAD DATA INFILE
al servidor. La opción
--local
hace que
mysqlimport lea ficheros de datos desde el
equipo cliente. Puede especificar la opción
--compress
para obtener un mejor rendimiento
en redes lentas si el cliente y el servidor soportan el
protocolo comprimido. Consulte Sección 8.9, “El programa para importar datos mysqlimport”.
Si usa LOW_PRIORITY
, la ejecución del
comando LOAD DATA
se retarda hasta que no
haya más clientes leyendo de la tabla.
Si especifica CONCURRENT
con una tabla
MyISAM
que satisfaga la condición para
inserciones concurrentes (esto es, no contiene bloques libres en
medio), entonces otros flujos pueden recibir datos desde la
tabla mientras se ejecuta LOAD DATA
. Usar
esta opción afecta al rendimiento de LOAD
DATA
ligeramente, incluso si no hay otro flujo usando
la tabla al mismo tiempo.
Si se especifica LOCAL
, se interpreta
respecto al cliente final de la conexión:
Si especificamos LOCAL
, el programa
cliente lee el fichero en el equipo cliente y lo envía al
servidor. Podemos indicar la ruta completa del fichero para
especificar su localización exacta. Si indicamos la ruta
relativa, el fichero se interpreta relativo al directorio en
el que el cliente se inició.
Si no se especifica LOCAL
, el fichero
tiene que estar en el equipo servidor y el servidor lo lee
directamente.
Al localizar ficheros en el equipo servidor, el servidor usa las siguientes reglas:
Si se da una ruta absoluta, el servidor usa la ruta como tal.
Si se da una ruta relativa con uno o más componentes, el servidor busca este fichero relativo al directorio de datos del servidor.
Si se da un nombre de fichero sin ninguna ruta, el servidor busca el fichero en el directorio de base de datos de la base de datos por defecto.
Tenga en cuenta que estas reglas significan que un fichero
llamado ./myfile.txt
se lee del directorio
de datos del servidor, mientras que el mismo fichero llamado
como myfile.txt
se lee desde el directorio
de base de datos de la base de datos por defecto. Por ejemplo,
el siguiente comando LOAD DATA
lee el fichero
data.txt
del directorio de la base de datos
para db1
porque db1
es la
base de datos actual, incluso si el comando carga
explícitamente el fichero en una tabla en la base de datos
db2
:
mysql> USE db1; mysql> LOAD DATA INFILE 'data.txt' INTO TABLE db2.my_table;
Tenga en cuenta que las rutas de windows se especifican usando barras en lugar de antibarras. Si usa barras, debe doblarlas.
Por razones de seguridad, al leer ficheros de texto localizados
en el servidor, los ficheros deben residir en el directorio de
la base de datos o ser leíbles por todo el mundo. Además, para
usar LOAD DATA INFILE
en ficheros del
servidor, debe tener el permiso FILE
.
Consulte Sección 5.6.3, “Privilegios de los que provee MySQL”.
Usar LOCAL
es un poco más lento que dejar al
servidor acceder al fichero directamente, porque el contenido
del fichero debe enviarse por la conexión desde el cliente al
servidor . Por otra parte, no necesita el permiso
FILE
para cargar ficheros locales.
En MySQL 5.0, LOCAL
funciona sólo si su
servidor y su cliente lo tienen activado. Por ejemplo, si
mysqld se arranca con
--local-infile=0
, entonces
LOCAL
no funciona. Consulte
Sección 5.5.4, “Cuestiones relacionadas con la seguridad y LOAD DATA
LOCAL
”.
Si necesita LOAD DATA
para leer desde un
pipe, puede usar la siguiente técnica (aquí cargamos el
listado del directorio /
en una tabla):
mkfifo /mysql/db/x/x chmod 666 /mysql/db/x/x find / -ls > /mysql/db/x/x mysql -e "LOAD DATA INFILE 'x' INTO TABLE x" x
Las palabaras REPLACE
y
IGNORE
controlan el tratamiento de registros
de entrada que duplican registros existentes en claves únicas.
Si especifica REPLACE
, los registros de
entrada reemplazan registros existentes (en otras palabras, los
registros que tienen el mismo valor para una clave primaria o
única que un registro existente). Consulte
Sección 13.2.6, “Sintaxis de REPLACE
”.
Si especifica IGNORE
, los registros de
entrada que dupliquen un registro existente en una clave única
se ignoran. Si no especifica ninguna opción, el comportamiento
depende de si la palabra LOCAL
se ha
especificado o no. Sin LOCAL
, ocurre un error
cuando se encuentra un valor de clave duplicado, y el resto del
fichero de texto se ignora. Con LOCAL
, el
comportamiento por defecto es el mismo que si se especifica
IGNORE
, esto es porque el servidor no tiene
forma de parar la transmisión del fichero en medio de la
operación.
Si quiere ignorar restricciones de clave foránea durante la
operación de carga, puede realizar un comando SET
FOREIGN_KEY_CHECKS=0
antes de ejecutar LOAD
DATA
.
Si usa LOAD DATA INFILE
en una tabla vacía
MyISAM
, todos los índices no únicos se
crean en batch separados (como para REPAIR
TABLE
). Esto hace LOAD DATA INFILE
mucho más rápido cuando tiene varios índices. Normalmente
esto es muy rápido, pero en algunos casos extromos, puede crear
los índices incluso más rápido desactivándolos con
ALTER TABLE ... DISABLE KEYS
antes de cargar
el fichero en la tabla y usar ALTER TABLE ... ENABLE
KEYS
para recrear los índices tras cargar el fichero.
Consulte Sección 7.2.14, “Velocidad de la sentencia INSERT
”.
LOAD DATA INFILE
es el complemento de
SELECT ... INTO OUTFILE
. (Consulte
Sección 13.2.7, “Sintaxis de SELECT
”.) Para escribir datos de una tabla en
un fichero use SELECT ... INTO OUTFILE
. Para
leer el fichero de nuevo en una tabla, use LOAD DATA
INFILE
. La sintaxis de las cláusulas
FIELDS
y LINES
es la misma
para ambos. Ambas son opcionales, pero FIELDS
debe preceder a LINES
si se especifican
ambas.
Si especifica una cláusula FIELDS
, cada una
de sus subcláusulas (TERMINATED BY
,
[OPTIONALLY] ENCLOSED BY
, y ESCAPED
BY
) también es opcional, excepto que debe especificar
al menos una de ellas.
Si no especifica una cláusula FIELDS
, por
defecto es como si hubiera escrito esto:
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'
Si no especifica una cláusula LINES
, por
defecto es como si hubiera escrito esto:
LINES TERMINATED BY '\n' STARTING BY ''
En otras palabras, por defecto LOAD DATA
INFILE
actúa como sigue al leer la entrada:
Busca delimitadores de línea como nuevas líneas.
No ignora ningún prefijo de línea.
Rompe las líneas en campos con los tabuladores.
No espera campos entrecomillados dentro de ningún carácter delimitador.
Interpreta las ocurrencias de tabuladores, nuevas líneas o
'\
' precedidas por '\
'
como caracteres literales que son parte de valores de
campos.
Por defecto SELECT ... INTO OUTFILE
actúa
como sigue al escribir la salida:
Escribe tabuladores entre campos.
No entrecomilla los campos.
Usa '\
' para escapar las instancias de
tabuladores, nuevas líneas o '\
' que
ocurren entre valores de campos.
Escribe nuevas líneas al final de las líneas.
Tenga en cuenta que para escribir FIELDS ESCAPED BY
'\\'
, debe escribir dos antibarras para que se
interprete como una única antibarra.
Nota: Si ha generado el fichero
de texto en un sistema Windows , puede tener que usar
LINES TERMINATED BY '\r\n'
para leer
correctamente el fichero, ya que los programas de Windows
típicamente usan dos caracteres como terminadores de línea .
Algunos programas como WordPad, pueden usar
\r
como terminador de línea al escribir
ficheros. Para leer tales ficheros, use LINES
TERMINATED BY '\r'
.
Si todas las líneas que quiere leer tienen un prefijo común
que quiere ignorar, puede usar LINES STARTING BY
'
para
ignorar el prefijo (y cualquier cosa antes del mismo). Si una
línea no incluye el prefijo, la línea entera se ignora.
Nota
prefix_string
'prefix_string
puede ocurrir en medio de una
línea.
Ejemplo:
mysql> LOAD DATA INFILE '/tmp/test.txt' -> INTO TABLE test LINES STARTING BY "xxx";
Con esto puede leer en un fichero que contenga algo como:
xxx"row",1 something xxx"row",2
Y obtener los datos ("row",1)
y
("row",2)
.
La opción IGNORE
puede usarse para ignorar líneas al inicio del
fichero. Por ejemplo, puede usar number
LINESIGNORE 1
LINES
para ignorar una cabecera inicial que contenga
los nombres de las columnas:
mysql> LOAD DATA INFILE '/tmp/test.txt' -> INTO TABLE test IGNORE 1 LINES;
Cuando usa SELECT ... INTO OUTFILE
junto con
LOAD DATA INFILE
para escribir datos desde
una base de datos en un fichero y luego lee datos del fichero de
nuevo en la base de datos, las opciones de tratamiento de
fichero y de línea para ambos comandos deben coincidir. De otro
modo, LOAD DATA INFILE
no interpreta los
contenidos del fichero correctamente. Suponga que usa
SELECT ... INTO OUTFILE
para escribir un
fichero con campos delimitados por comas:
mysql> SELECT * INTO OUTFILE 'data.txt' -> FIELDS TERMINATED BY ',' -> FROM table2;
Para leer el fichero delimitado por comas, el comando correcto sería:
mysql> LOAD DATA INFILE 'data.txt' INTO TABLE table2 -> FIELDS TERMINATED BY ',';
Si en lugar de esto trata de leer en el fichero con el comando
mostrado aquí, no funcionaría porque le dice a LOAD
DATA INFILE
que busque tabuladores entre campos:
mysql> LOAD DATA INFILE 'data.txt' INTO TABLE table2 -> FIELDS TERMINATED BY '\t';
El resultado esperado es que cada línea de entrada se interprete como un único campo.
LOAD DATA INFILE
puede usarse para leer
ficheros obtenidos de fuentes externas. Por ejemplo, un fichero
en formato dBASE tiene campos separados por comas y
entrecomillados por comillas dobles. Si las líneas en el
fichero se terminan con nuevas líneas, el comando mostrado
aquí ilustra las opciones de campo y línea que debería usar
para cargar el fichero:
mysql> LOAD DATA INFILE 'data.txt' INTO TABLE tbl_name
-> FIELDS TERMINATED BY ',' ENCLOSED BY '"'
-> LINES TERMINATED BY '\n';
Cualquiera de las opciones de tratamiento de campo o línea
pueden especificarse como una cadena vacía
(''
). Si no está vacía, los valores
FIELDS [OPTIONALLY] ENCLOSED BY
y
FIELDS ESCAPED BY
deben ser un único
carácter. Los valores FIELDS TERMINATED BY
,
LINES STARTING BY
, y LINES
TERMINATED BY
pueden tener más de un carácter . Por
ejemplo, para escribir líneas terminadas por parejas de retorno
de carro y nueva línea, o para leer un fichero conteniendo
tales líneas, especifique una cláusula LINES
TERMINATED BY '\r\n'
.
Para leer un fichero que contenga bromas separadas por líneas
consistentes de %%
, puede hacer lo siguiente
mysql> CREATE TABLE jokes -> (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, -> joke TEXT NOT NULL); mysql> LOAD DATA INFILE '/tmp/jokes.txt' INTO TABLE jokes -> FIELDS TERMINATED BY '' -> LINES TERMINATED BY '\n%%\n' (joke);
FIELDS [OPTIONALLY] ENCLOSED BY
controla el
entrecomillado de los campos. Para la salida (SELECT
... INTO OUTFILE
), si omite la palabra
OPTIONALLY
, todos los campos se delimitan por
el carácter ENCLOSED BY
. Un ejemplo de tal
salida (usando coma como el delimitador de campo) se muestra
aquí:
"1","a string","100.20" "2","a string containing a , comma","102.20" "3","a string containing a \" quote","102.20" "4","a string containing a \", quote and comma","102.20"
Si especifica OPTIONALLY
, el carácter
ENCLOSED BY
se usa sólo para delimitar
valores en columnas que tienen datos de cadenas (tales como
CHAR
, BINARY
,
TEXT
, o ENUM
):
1,"a string",100.20 2,"a string containing a , comma",102.20 3,"a string containing a \" quote",102.20 4,"a string containing a \", quote and comma",102.20
Tenga en cuenta que la ocurrencias del carácter
ENCLOSED BY
dentro de un campo se escapan
mediante un prefijo del carácter ESCAPED BY
.
También tenta en cuenta que si especifica un valor
ESCAPED BY
vacío, es posible generar salida
que no puede leerse correctamente con LOAD DATA
INFILE
. Por ejemplo, la salida precedente tendría la
siguiente apariencia si el carácter de escape estuviera vacío.
Observe que el segundo campo en la cuarta línea contiene una
coma siguiendo la delimitación, que (erróneamente) parece que
termine el campo:
1,"a string",100.20 2,"a string containing a , comma",102.20 3,"a string containing a " quote",102.20 4,"a string containing a ", quote and comma",102.20
Para entrada, el carácter ENCLOSED BY
, si
está presente, se elimina del final de los valores de campos .
(Esto es cierto se especifique OPTIONALLY
o
no; OPTIONALLY
no tiene efecto en la
interpretación de la entrada.) Las ocurrencias del carácter
ENCLOSED BY
prececdidas por el carater
ESCAPED BY
se interpretan como parte del
campo actual.
Si el campo comienza con el carácter ENCLOSED
BY
, las instancias del mismo se reorganizan como
terminadores del campo sólo si van seguidas por el campo o la
secuencia TERMINATED BY
. Para evitar
ambigüedad, las ocurrencias del carácter ENCLOSED
BY
dentro de un campo se pueden doblar y se
interpretan como una única instancia del carácter. Por
ejemplo, si se especifica ENCLOSED BY '"'
,
la delimitación se trata como se muestra aquí:
"The ""BIG"" boss" -> The "BIG" boss The "BIG" boss -> The "BIG" boss The ""BIG"" boss -> The ""BIG"" boss
FIELDS ESCAPED BY
controla cómo escribir o
leer caracteres especiales. Si el carácter FIELDS
ESCAPED BY
no está vacío, se usa como prefijo para
los siguientes caracteres de salida:
El carácter FIELDS ESCAPED BY
El carácter FIELDS [OPTIONALLY] ENCLOSED
BY
El primer carácter de los valores FIELDS
TERMINATED BY
y LINES TERMINATED
BY
ASCII 0
(lo que realmente se escribe a
continuación del carácter de escape es
'0
' en ASCCI, no un byte con valor cero)
Si el carácter FIELDS ESCAPED BY
está
vacío, no se escapan caracteres y NULL
se
muestra como NULL
, no \N
.
Probablemente no es una buena idea especificar un carácter de
escape vacío, particularmente si los valores de campos en sus
datos contienen cualquiera de los caracteres en la lista dada.
Para entrada, si el carácter FIELDS ESCAPED
BY
no está vacío, las ocurrencias del mismo se
eliminan y el siguiente carácter se toma literalmente como
parte del campo. Las excepciones son un '0
'
escapado o 'N
' (por ejemplo,
\0
o \N
si el carácter de
escape es '\
'). Estas secuencias se
interpretan como ASCII NUL (un byte con valor cero) y
NULL
. Las reglas para tratamiento de
NULL
se describen posteriormente.
Para más infomación de la sintaxis de escape
'\
' consulte Sección 9.1, “Valores literales”.
En ciertos casos, las opciones de tratamiento de campos y línea interactúan:
Si LINES TERMINATED BY
es una cadena
vacío y FIELDS TERMINATED BY
no está
vacío, las líneas se terminan con FIELDS
TERMINATED BY
.
Si los valores FIELDS TERMINATED BY
y
FIELDS ENCLOSED BY
están vacíois
(''
), se usa un formato fijo de registro
(no delimitado). Con este formato, no se usan delimitadores
entre campos (pero puede tener un terminador de línea). En
su lugar, los valores de columna se escriben y leen usando
los anchos de muestra de las columnas. Por ejemplo, si una
columna se declara como INT(7)
, los
valores para la columna se escriben usando campos de siete
caracteres. En la entrada, los valores para la columna se
obtienen leyendo siete caracteres.
LINES TERMINATED BY
se usa para separar
líneas. Si una línea no contiene todos los campos, el
resto de columnas se asignan con sus valores por defecto. Si
no tiene un terminador de línea, debe asignarlo a
''
. En este caso, el fichero de texto
debe contener todos los campos para cada registro.
El formato fijo de registro también afecta al tratamiento
de valores NULL
, como se describe
posteriormente. Tenga en cuenta que el formato de tamaño
fijo no funciona si está usando un conjunto de caracteres
multi byte.
El tratamiento de valores NULL
varía en
función de las opciones FIELDS
y
LINES
en uso:
Para los valores FIELDS
y
LINES
por defecto,
NULL
se escribe como
\N
para la salida, y
\N
para la entrada se lee como
NULL
(considerando que el carácter
ESCAPED BY
es '\
').
Si FIELDS ENCLOSED BY
no está vacílo,
un campo que contenga el literal NULL
como valor se lee como el valor NULL
.
Esto difiere de la palabra NULL
delimitada por caracteres FIELDS ENCLOSED
BY
, que se lee como la cadena
'NULL'
.
Si FIELDS ESCAPED BY
está vacío,
NULL
se escribe como la palabra
NULL
.
Con formato fijo de registro (lo que ocurre cuando
FIELDS TERMINATED BY
y FIELDS
ENCLOSED BY
están vacíos),
NULL
se escribe como una cadena vacía.
Teng en cuenta que esto hace que ambos valores
NULL
y cadenas vacías en la tabla sean
indistinguibles cuando se escriben en el fichero ya que
ambos se escriben como cadenas vacías. Si necesita
distinguir entre ambos al leer del fichero, no debe usar el
formato de registro fijo.
Algunos casos no son soportados por LOAD DATA
INFILE
:
Registros de tamaño fijo (FIELDS TERMINATED
BY
y FIELDS ENCLOSED BY
ambos
vacíos) y columnas BLOB
o
TEXT
.
Si especifica un separador que es igual o prefijo de otro,
LOAD DATA INFILE
no será capaz de
interpretar la entrada correctamente. Por ejemplo, la
siguiente cláusula FIELDS
causaría
problemas:
FIELDS TERMINATED BY '"' ENCLOSED BY '"'
Si FIELDS ESCAPED BY
está vacío, un
valor que contenga una ocurrencia de FIELDS
ENCLOSED BY
o LINES TERMINATED
BY
seguido por el valor FIELDS TERMINATED
BY
causa que LOAD DATA INFILE
pare de leer un campo o línea demasiado rápido. Esto
ocurre porque LOAD DATA INFILE
no puede
determinar apropiadamente dónde acaba el campo o línea.
El siguiente ejemplo carga todas las columnas de la tabla
persondata
:
mysql> LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata;
Por defecto, cuando no se proporciona una lista al final de un
comando LOAD DATA INFILE
, las líneas de
entrada se espera que contengan un campo para cada columna de la
tabla. Si quiere cargar sólo algunas columnas de una tabla,
especifique una lista de columnas:
mysql> LOAD DATA INFILE 'persondata.txt' -> INTO TABLE persondata (col1,col2,...);
Debe especificar una lista de columnas si el orden de los campos del fichero de entrada difiere del orden de las columnas en la tabla. De otro modo, MySQL no puede decir cómo hacer coincidir los campos de entrada con las columnas de la tabla.
Antes de MySQL 5.0.3, la lista de columnas debe contener sólo
nombres de columnas en la tabla que se carga, y la cláusula
SET
no se soporta. Desde MySQL 5.0.3, la
lista de columnas puede contener nombres de columna o variables
y la cláusula SET
se soporta. Esto le
permite asignar valores de entrada a variables de usuario, y
luego realizar transformaciones on estos valores antes de
asignar los resultados a las columnas.
Las variables de usuario en la cláusula SET
puede usarse de distintos modos. El siguiente ejemplo usa la
primera columna en el fichero de datos directamente para el
valor de t1.column1
, y asigna la segunda
columna a una variable de usuario que está sujeta a una
operación de división antes de ser usada por el valor de
t2.column2
:
LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
La cláusula SET
puede usarse para
proporcionar valores no derivados del fichero de entrada. Los
siguientes comandos actualizan column3
con la
fecha y hora actuales:
LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, column2) SET column3 = CURRENT_TIMESTAMP;
También puede descartar un valor de entrada asignándolo a una variable de usuario y no asignando la variable a una columna de tabla:
LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @dummy, column2, @dummy, column3);
El uso de la lista de columnas/variables y la cláusula
SET
está sujeto a las siguientes
restricciones:
Las asignaciones en la cláusula SET
deben tener sólo nombres de columna en el lado izquierdo
del operador de asignación.
Puede usar subconsultas en la parte derecha de la
asignación de SET
. Una subconsulta que
retorne un valor a ser asignado a otra coluimna sólo puede
ser una subconsulta escalar. Además, no puede usar una
subconsulta para seleccionar desde la tabla que se está
cargando.
Las líneas ignoradas por un cláusula
IGNORE
no se procesan por parta de la
lista de columnas/variables o por la cláusula
SET
.
Las variables de usuario no pueden usarse al cargar datos con formato de registo ya que las variables de usuario no tienen un ancho de muestra.
Al procesar una línea de entrada, LOAD DATA
la divide en campos y usa los valores según la lista de
columnas/ variables y la cláusula SET
, si
están presentes. A continuación se inserta el registro
resultante en la tabla. Si hay disparadores BEFORE
INSERT
o AFTER INSERT
para la
tabla, se activan antes o después de insertar el registro,
respectivamente.
Si una línea de entrada tiene demasiados campos, los campos extra se ignoran y el número de advertencias se incrementa.
Si una línea de entrada no tiene suficientes campos, las
columnas de la tabla que no tienen entrada adquieren su valor
por defecto. Los valores por defecto se describen en
Sección 13.1.5, “Sintaxis de CREATE TABLE
”.
Un valor de campo vacío se interpreta de forma distinta que si el valor no está presente:
Para tipos de cadenas, la columna adquiere la cadena vacía.
Para tipos numéricos, la columna recibe el valor
0
.
Para tipos de fecha y hora, la columna obtiene el valor “cero” apropiado para el tipo. Consulte Sección 11.3, “Tipos de fecha y hora”.
Estos son los mismos valores que resultan si asigna una cadena
vacía explícitamente a un tipo de cadena de caracteres,
numérico o de fecha u hora en un comando
INSERT
o UPDATE
statement.
Las columnas TIMESTAMP
obtienen la fecha y
hora actuales sólo si hay un valor NULL
para
la columna (esto es, \N
), o (para la primera
columna TIMESTAMP
únicamente) si se omite
TIMESTAMP
de la lista de campos cuando se
especifica una.
LOAD DATA INFILE
trata todas las entradas
como cadenas, asi que no puede usar valores numéricos para
columnas ENUM
o SET
del
modo en que puede hacerlo con comandos INSERT
. Todos los valores ENUM
y
SET
deben especificarse como cadenas.
Cuando acaba el comando LOAD DATA INFILE
,
retorna una cadena de información con el siguiente formato:
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
Si usa la API de C, puede obtener información acerca del
comando mediante la función mysql_info()
.
Consulte Sección 24.2.3.32, “mysql_info()
”.
Las advertencias se producen bajo las mismas circunstancias que
cuando los valores se insertan mediante el comando
INSERT
(consulte Sección 13.2.4, “Sintaxis de INSERT
”),
excepto que LOAD DATA INFILE
también genera
advertencias cuando hay muy pocos o demasiados campos en el
registro de entrada. Las advertencias no se almacenan en ningún
lugar; el número de las mismas puede usarse sólo como
indicación de si todo ha ido bien.
En MySQL 5.0, puede usar SHOW WARNINGS
para
obtener una lista de las primeras
max_error_count
advertencias como
información acerca de qué ha fallado. Consulte
Sección 13.5.4.22, “Sintaxis de SHOW WARNINGS
”.
Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.