Mysqlloaddatainfile usage _ MySQL

Use bitsCN.com for mysqlloaddatainfile

Load data [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name.txt'

[REPLACE | IGNORE]

Into table tbl_name

[FIELDS

[Terminated by 'string']

[[OPTIONALLY] enclosed by 'char ']

[Escaped by 'char ']

]

[LINES

[Starting by 'string']

[Terminated by 'string']

]

[IGNORE number LINES]

[(Col_name_or_user_var,...)]

[SET col_name = expr,...]

The load data infile statement reads rows from a text file to a table at a high speed. The file name must be a text string.

For more information about the efficiency of INSERT and load data infile and how to increase the speed of load data infile, refer to the accelerated INSERT statement in the Administrator Manual.

The character set specified by the system variable character_set_database is used to interpret information in the file. Set names and character_set_client do not affect the input interpretation.

You can also use the import utility to load data files. it is implemented by sending a load data infile command to the server. The -- local option enables import to read data files from the client host. If the client and server support the compression protocol, you can specify the -- compress option to achieve better performance in a slow network. See the import-data import program in the Administrator Manual.

If you specify the keyword LOW_PRIORITY, the execution of the load data statement will be delayed until no other client is reading the table.

If a GSSYS table meets the conditions for simultaneous insertion (that is, the table has idle blocks in the middle) and you specify CONCURRENT for the GSSYS table, when load data is being executed, other threads will re-obtain data from the table. Even if no other thread is using this table at the same time, using this option will slightly affect the performance of load data.

If the LOCAL keyword is specified, it will explain the connected client:

• If LOCAL is specified, the client component on the client host reads the file and sends it to the server. You can provide the complete path of the file to determine its exact location. If the relative path is given, the file name is relative to the directory where the client component was started.

• If LOCAL is not specified, the file is located on the server host and is directly read by the server.

When files are located from the server host, the server uses the following rules:

• If a complete path is given, the server uses this path name.

• If the relative path of one or more front components is specified, the server searches for files in a directory relative to the server.

• If a file name without a front component is specified, the server searches for files from the Database Directory of the current database.

Note:

These rules mean that the file given by '/gsfile.txt' is read from the data directory of the server. However, the file given by 'gsfile.txt 'is read from the data directory of the current database. For example, the following load data Statement reads the 'data.txt 'file from the db1 DATA warehouse Directory. because db1 is the current database, even if the statement explicitly loads the file into the db2 database table, it reads it from the db1 Directory:

Sqlcli> USE db1;

Sqlcli> load data infile 'data.txt 'into table db2.gs _ table;

Note:

When specifying a Windows path name, a diagonal line rather than a backslash is used. To use a backslash, you must double-write.

For security reasons, when reading text files on the server, the files must be in the database directory or can be read by all users. That is to say, when you execute load data infile for files on the server, you must obtain the FILE permission.

Refer to the permissions provided by GBase in the Administrator Manual.

Compared with the direct access to files on the server, the LOCAL access speed is slightly slower, because the file content must be transmitted through a connection from the client to the server. On the other hand, you do not need to obtain the FILE permission for local files.

LOCAL can work only when both the server and client are allowed. For example, if -- local-infile = 0 when the kernel is started, LOCAL cannot work. See the load data local security questions in the Administrator Manual.

The REPLACE and IGNORE keywords process input records that are repeated with existing primary key values.

If REPLACE is specified, the input row replaces the existing row (that is, the row with the same primary index value as the existing row ). Refer to the REPLACE syntax.

If IGNORE is specified, the input row that already has a primary key value is skipped. If either of them is not specified, the operation behavior depends on whether the LOCAL keyword is specified. If no LOCAL is specified, if duplicate key values are found, an error is generated and the rest of the text file is ignored. If LOCAL is specified, the default operation will be the same as the IGNORE; this is because the server cannot terminate file transfer during the operation.

If you want to ignore the foreign key constraints in the LOAD operation, you can execute the SET FOREIGN_KEY_CHECKS = 0 statement before running load data.

If you use load data infile on an empty GsSYS table, all non-unique indexes will be created in batches (like REPAIR ). When there are many indexes, this usually makes load data infile faster. Normally, it is very fast, but there are also extreme cases. you can use alter table before loading the file .. disable keys close them and use alter table after loading the file .. enable keys re-indexing to accelerate index creation. See the accelerated INSERT statement in the Administrator Manual.

Load data infile is the inverse operation of SELECT... into outfile. See SELECT syntax. Use SELECT... into outfile to write data from a database to a file. Use load data infile to read files to the database. The syntax of the FIELDS and LINES clauses of the two commands is the same. Both clauses are optional, but if both clauses are specified at the same time, the FIELDS clause must appear before the LINES clause.

If you specify a FIELDS clause, its clauses (terminated by, [OPTIONALLY] enclosed by, and escaped by) are also optional. However, you must specify at least one of them.

If you do not specify a FIELDS clause, the following statement is used for saving time:

Fields terminated by '/t' enclosed by ''escaped '//'

If you do not specify a LINES clause, the following statements are used for saving time:

Lines terminated by '/N' starting''

In other words, when reading input, the default load data infile is as follows:

• Find the line boundary at the line break.

• No row prefix is missing.

• Separate rows into fields at the TAB.

• Fields are not considered to be enclosed by any quotation marks.

• A positioning character, line break, or '/' starting with "/" is interpreted as a text character of the field value.

On the contrary, when writing data to the output, the default value causes SELECT... into outfile to behave as follows:

• Add a tab between field values.

• Fields are enclosed without any quotation marks.

• Use "/" to escape the location, line break, or '/' character instance that appears in the field value.

• Add a line break at the end of the row.

Note:

To write fields escaped by '//', you must specify two backslashes. this value is read as a backslash.

Note:

If it is a Windows text file, you may have to use lines terminated by '/r/N' to read the file, because Windows uses two characters as the line terminator. In some programs,/r may be used as the line terminator when writing a file, such as a WordPad. Use lines terminated by '/r' to read such files '.

If all rows to be read have prefixes that you want to ignore, you can use lines starting by 'Prefix _ string' to skip this prefix (and any content before it ). If a row does not have this prefix, the entire row is skipped. Note: prefix_string may be in the middle of the row!

For example:

Sqlcli> load data infile '/tmp/test.txt'

-> Into table test lines starting by "xxx ";

Use it to read files containing the following content:

Xxx "Row", 1

Something xxx "Row", 2

Then we can get the data ("row", 1) and ("row", 2 ).

The IGNORE number LINES option can be used to IGNORE the rows at the beginning of the file. For example, you can use IGNORE 1 LINES to skip the first line containing the column name:

Sqlcli> load data infile '/tmp/test.txt'

-> Into table test IGNORE 1 LINES;

When you use SELECT... into outfile and load data infile write DATA from a database to a file, and then read it INTO the database from the file, the fields of the two commands and the row processing options must match. Otherwise, load data infile cannot correctly interpret the file content. Assume that you use SELECT... into outfile to write data to a file using comma-separated fields:

Sqlcli> SELECT * into outfile 'data.txt'

-> Fields terminated ','

-> FROM table2;

The correct statement should be:

Sqlcli> load data infile 'data.txt 'into table table2

-> Fields terminated ',';

If you try to read the file with the following statement, it will not work, because the command load data infile distinguishes the field value with a positioning character:

Sqlcli> load data infile 'data.txt 'into table table2

-> Fields terminated by '/t ';

The possible result is that each input row is interpreted as a separate field.

Load data infile can also be used to read files obtained from external sources. For example, in a file in dBASE format, fields are separated by commas and surrounded by double quotation marks. If the row in the file is terminated with a line break, the following describes the fields and row processing options that the user will use to load the file:

Sqlcli> load data infile 'data.txt 'into table tbl_name

-> Fields terminated by ', 'enabledby '"'

-> Lines terminated by '/N ';

You can specify an empty string ('') for any field or row processing option (''). If it is not empty, the values of FIELDS [OPTIONALLY] enclosed by and fields escaped by must be a single character. The fields terminated by and lines terminated by values can exceed one character. For example, to write a row terminated by a carriage return or read a file containing such a row, specify a line terminated by '/r/N' clause.

FIELDS [OPTIONALLY] enclosed by control field reference. For output (SELECT... into outfile), if you omit the word OPTIONALLY, all fields are surrounded BY the enclosed by characters. An example of such an output file (using a comma as the field separator) is as follows:

"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"

If you specify OPTIONALLY, the enclosed by character is only used to wrap fields that contain string types (such as CHAR, BINARY, TEXT, or 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

Note:

The enclosed by character in a field value is escaped by using the escaped by character as its prefix. Note that if you specify an empty escaped by value, an output file that cannot be correctly read by load data infile may be generated. For example, if the escape character is empty, the output shown above will be the output shown below. Note that the second field in the fourth row contains a comma following a quotation mark, which looks like the termination of a field:

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

For input, if the enclosed by character exists, it will be stripped from the end of the field value. (Whether OPTIONALLY is specified or not. OPTIONALLY does not affect the input interpretation .) If the escaped by character exists before the enclosed by character, it is interpreted as part of the current field value.

If the field starts with the ENCLOSED character, as long as it is followed BY the field or the line terminated by sequence, this character instance is considered to be used to terminate a field value. To make it clear that if the enclosed by character is used in a field, you can repeat the character twice, and they will be interpreted as a single enclosed by character. For example, if enclosed by '"' is specified, the quotation marks are processed as follows:

"The" "BIG" "boss"-> The "BIG" boss

The "BIG" boss-> The "BIG" boss

The "" BIG "" boss-> The "" BIG "" boss

Fields escaped by controls how to write or read special characters. If the fields escaped by character is not empty, it will be used as the prefix of the following output characters:

• Fields escaped by character

• FIELDS [OPTIONALLY] enclosed by character.

• The first character of fields terminated by and lines terminated by values.

• ASCII 0 (in fact, ASCII '0' is written after the escape character, rather than a zero-value byte ).

If the fields escaped by character is NULL, no characters are ESCAPED and the NULL value is still output as NULL instead of/N. Specifying an empty escape character may not be a good method, especially when the user's data field value contains any character in the list.

For the input value, if the fields escaped by character is not a null character, this character is stripped and the following characters are used as part of the field value. The exception is that the escaped '0' or 'N' (for example,/0 OR/N, and the escape character is '/'). These sequences are understood as ascii nul (a zero-value byte) and NULL. Rules for NULL processing are described at the back of this section.

For more "/" Escape syntax information, view the text value.

In some cases, field and row processing interact:

• If lines terminated by is an empty string and fields terminated by is not empty, each row ends with fields terminated.

• If the values of fields terminated by and fields enclosed by are both null (''), a fixed row (with no delimiters) format will be used. When fixed line format is used, no separator is used between fields (but the user still has a line terminator ). Write and read column values using the "display" width of the column. For example, if a column is defined as INT (7), the column value is written with a field of 7 characters. For input, the column value is obtained by reading 7 characters.

Lines terminated by is still used to separate rows. If a row does not contain all fields, the remaining parts of the column are set to their default values. If you do not have a line terminator, you should set it ''. In this case, the text file must contain all fields in each line.

The fixed row format also affects the processing of NULL values. See the following. Note that if you are using a multi-byte character set, the fixed length format will not work.

There are many NULL values processed, depending on the FIELDS and LINES options used by the user:

• For the default FIELDS and LINES values, NULL is written as/N during output, and/N is read as NULL (assume that the escaped by character is "/").

• If fields enclosed by is not a NULL value, the FIELDS containing NULL words are read as NULL values. This is different from NULL, which is surrounded by fields enclosed by characters. The word is read as the string 'Null.

• If fields escaped by is empty, the NULL value is written as the word NULL.

• When the regular row format is used (when fields terminated by and fields enclosed by are both NULL), NULL is written as an empty string. Note: When a file is written, the NULL value and NULL string in the table cannot be identified because both are written as NULL strings. If you need to distinguish the two when reading the file and returning it, you should not use a fixed row format.

Some situations that cannot be supported by load data infile:

• Fixed-size record rows (fields terminated by and fields enclosed by are empty) and BLOB or TEXT columns.

• If you specify a separator that is the same as the other, or a prefix of the other, load data infile may not properly interpret the input. For example, the following FIELDS clause may cause problems:

Fields terminated by '"'enabledby '"'

•

• If fields escaped by is null and a field value contains the value of fields enclosed by or line terminated by followed by fields terminated, this will cause the load data infile to stop reading a field or a row too early. This is because load data infile does not know where the field or row value ends.

The following example loads all columns in the persondata table:

Sqlcli> load data infile 'persondata.txt 'into table persondata;

By default, when a field column is not provided after the load data infile statement, load data infile considers the input row to contain all fields in the table column. If you want to load certain columns in the table, specify a field list:

Sqlcli> load data infile 'persondata.txt'

-> Into table persondata (col1, col2 ,...);

If the field order of the input file is different from that of the columns in the table, you must specify a field list. Otherwise, GBase does not know how to match the input field with the column in the table.

The Column list can contain Column names or user variables, and supports the SET clause. This allows you to assign values to user variables using input values and convert these values before assigning the results to the columns.

User variables in the SET clause have multiple purposes. In the following example, the first column of the data file is directly used as the value of t1.column1, and the second column is assigned to a user variable. this variable performs a division operation before being used as the value of t2.column2.

Load data infile 'file.txt'

Into table t1

(Column1, @ var1)

SET column2 = @ var1/100;

The SET clause can provide values that are not from the input file. The following statement sets column3 to the current date and time:

Load data infile 'file.txt'

Into table t1

(Column1, column2)

SET column3 = CURRENT_TIMESTAMP;

By assigning an input value to a user variable, you can discard this input value without assigning this value to a column in the table:

Load data infile 'file.txt'

Into table t1

(Column1, @ dummy, column2, @ dummy, column3 );

The use of the column/variable list and SET clause is subject to the following restrictions:

• The value assignment column in the SET clause must be on the left of the value assignment operator.

• In the SET value assignment statement, subqueries can be used. This query returns a value that will be assigned to the column. it may be just a scalar query. You cannot use subqueries to query the tables to be imported.

• For the column/variable list or SET clause, IGNORE rows because the IGNORE clause is used will not be processed.

• Because User variables do not display width, user variables cannot be used when the imported data is in fixed row format.

When processing input rows, load data divides the rows into fields. if the column/variable list and SET clause are provided, these values will be used according to it. Then the row is inserted into the table. If this table has before insert or after insert triggers, they are activated BEFORE and AFTER the inserted rows.

If there are too many fields in the input record line, extra fields will be ignored and the number of warnings will be increased.

If there are few fields in an input row, columns without input fields are set to the default value. The default value assignment is described in the create table syntax.

An empty field value is different from the loss of the field value:

• For the string type, the column is set to a null string.

• For the numeric type, the column is set to 0.

• For the date and time types, the column is set to the "zero" value suitable for the column type. Refer to date and time types.

If an empty string is explicitly assigned to a string, number, date, or time type in an INSERT or UPDATE statement, the user will get the same result as above.

The TIMESTAMP column is set to the current date and time only in two cases. One case is that the column has a NULL value (that is,/N); the other case is (only for the first TIMESTAMP column). when a field list is specified, the TIMESTAMP column is omitted from the field list.

Load data infile considers all input strings. Therefore, you cannot SET numeric values for ENUM or SET columns in the form of an INSERT statement. All ENUM and SET values must be specified as strings!

When the load data infile query ends, it returns an information string in the following format:

Records: 1 Deleted: 0 Skipped: 0 Warnings: 0

BitsCN.com