Backing Up with SELECT INTO

Backing Up with SELECT INTO

Another way to perform a backup is to use SELECT INTO. This is similar to mysqldump in that it creates a file that is used to re-create the backed-up table. It is also the opposite of the LOAD DATA INTO statement. The resulting file can only be created on the MySQL server, not any other host. The syntax is as follows:

SELECT … INTO OUTFILE 'path_and_filename'

Any valid SELECT can be used to create a file.

To create a backup of the customer table, you would do the following, firstly on Unix:

mysql> SELECT * FROM customer INTO OUTFILE '/db_backups/customer.dat'; Query OK, 8 rows affected (0.00 sec)

And then on Windows:

mysql> SELECT * FROM customer INTO OUTFILE 'c:\\db_backups\\bdb.dat'; Query OK, 8 rows affected (0.33 sec)

Once again, you need to be careful when doing this. The following error is common:

mysql> SELECT * FROM customer INTO OUTFILE '/db_backups/customer.dat'; ERROR 1086: File '/db_backups/customer.dat' already exists

You cannot overwrite an existing file (which provides some sort of security, as a badly set up system may allow critical files to be overwritten).

Another common error is the following, from Windows:

mysql> SELECT * FROM customer INTO OUTFILE 'c:\db_backups\customer.dat'; ERROR 1: Can't create/write to file 'c:db_backupscustomer.dat' (Errcode: 2)

The error message here is quite clear: MySQL cannot write to this directory because you've forgotten to escape \ characters. \ in Windows is the escape character, and because it's also part of the Windows path, it needs to be escaped when used in that context. On Unix, a similar error is common:

mysql> SELECT * FROM customer INTO OUTFILE '\db_backups\customer.dat'; Query OK, 8 rows affected (0.18 sec)

In this case, though, MySQL does not even warn you of an error. Somebody from a Windows environment could easily put the slashes the wrong way and not get their backup. Always check that your backup has been created.

Looking at the file in any text editor (such as vi or Notepad), you'll see the following:

1       Yvonne  Clegg   X 2       Johnny  Chaka-Chaka     B 3       Winston Powers  M 4       Patricia        Mankunku        C 5       Francois        Papo    P 7       Winnie  Dlamini \N 6       Neil    Beneke  \N 10      Breyton Tshabalala      B

Tabs separate the fields, and newlines separate the records, which is the same default used by LOAD DATA INTO. You can also change these defaults by adding options at the end of the statement. The full set of options for SELECT INTO (and LOAD DATA INTO) is as follows:

[FIELDS         [TERMINATED BY '\t']         [[OPTIONALLY] ENCLOSED BY '']         [ESCAPED BY '\\' ]     ]     [LINES TERMINATED BY '\n']

Here are some examples of using non-default options when using SELECT INTO, and the resulting text files:

mysql> SELECT * FROM customer INTO OUTFILE '/db_backups/customer2.dat'  FIELDS TERMINATED BY 'zz'; Query OK, 8 rows affected (0.00 sec)

The data looks like the following:

1zzYvonnezzCleggzzX 2zzJohnnyzzChaka-ChakazzB 3zzWinstonzzPowerszzM 4zzPatriciazzMankunkuzzC 5zzFrancoiszzPapozzP 7zzWinniezzDlaminizz\N 6zzNeilzzBenekezz\N 10zzBreytonzzTshabalalazzB 

The default tab character is replaced by the characters zz between each field.

Warning 

The characters zz are used here just to make a point. It is dangerous to use ordinary characters like this as terminators. If the text contained the phrase zzz, the fields would all be out of alignment, as MySQL would think the first two characters were a terminator. Use conventional characters such as tabs, newlines, or piping (|) for your terminators.

This next statement creates one long line:

mysql> SELECT * FROM customer INTO OUTFILE '/db_backups/customer3.dat'  FIELDS TERMINATED BY '|' LINES TERMINATED BY '[end]'; Query OK, 8 rows affected (0.00 sec)

The data appears as shown:

1|Yvonne|Clegg|X[end]2|Johnny|Chaka-Chaka|B[end]Ã 3|Winston|Powers|M[end]4|Patricia|Mankunku|C[end]Ã 5|Francois|Papo|P[end]7|Winnie|Dlamini|\N[end]Ã 6|Neil|Beneke|\N[end]10|Breyton|Tshabalala|B[end]

The line breaks are replaced by the characters [end].

In the following example, the ENCLOSED keyword surrounds all fields by the specified characters:

mysql> SELECT * FROM customer INTO OUTFILE '/db_backups/customer4.dat'  FIELDS TERMINATED BY '|' ENCLOSED BY '"' LINES TERMINATED BY '\n'; Query OK, 8 rows affected (0.00 sec)

The data appears as the following:

"1"|"Yvonne"|"Clegg"|"X" "2"|"Johnny"|"Chaka-Chaka"|"B" "3"|"Winston"|"Powers"|"M" "4"|"Patricia"|"Mankunku"|"C" "5"|"Francois"|"Papo"|"P" "7"|"Winnie"|"Dlamini"|\N "6"|"Neil"|"Beneke"|\N "10"|"Breyton"|"Tshabalala"|"B"

The OPTIONALLY keyword results in only character fields being enclosed (just as you enclose character fields in single quotes when adding records, but not numeric fields). For example:

mysql> SELECT * FROM customer INTO OUTFILE '/db_backups/customer5.dat'  FIELDS TERMINATED BY '|' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED  BY '\n'; Query OK, 8 rows affected (0.00 sec) 

The first field of the data (it's type INT) is not enclosed with quotes:

1|"Yvonne"|"Clegg"|"X" 2|"Johnny"|"Chaka-Chaka"|"B" 3|"Winston"|"Powers"|"M" 4|"Patricia"|"Mankunku"|"C" 5|"Francois"|"Papo"|"P" 7|"Winnie"|"Dlamini"|\N 6|"Neil"|"Beneke"|\N 10|"Breyton"|"Tshabalala"|"B"

You can also back up a subset of the data, using a condition in your SELECT statement:

mysql> SELECT * FROM customer WHERE id<10 INTO OUTFILE  '/db_backups/customer6.dat' FIELDS TERMINATED BY '|' LINES TERMINATED  BY '\n'; Query OK, 7 rows affected (0.01 sec)

Only the seven applicable records appear in the file:

1|Yvonne|Clegg|X 2|Johnny|Chaka-Chaka|B 3|Winston|Powers|M 4|Patricia|Mankunku|C 5|Francois|Papo|P 7|Winnie|Dlamini|\N 6|Neil|Beneke|\N

Restoring a Table with LOAD DATA

To restore a table created with SELECT INTO, use the LOAD DATA statement. You can also use LOAD DATA to add data that has been created in some other way, perhaps an application or a spreadsheet. It is the fastest way to add data, especially large quantities of data. The syntax is as follows:

LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'filename'     [REPLACE | IGNORE]     INTO TABLE tbl_name     [FIELDS         [TERMINATED BY '\t']         [[OPTIONALLY] ENCLOSED BY '']         [ESCAPED BY '\\' ]     ]     [LINES TERMINATED BY '\n']     [IGNORE number LINES]     [(col_name,...)]

Let's remove the data from the customer table and restore it using LOAD DATA:

mysql> TRUNCATE customer; Query OK, 0 rows affected (0.02 sec) 

To restore the table on Unix, use:

mysql> LOAD DATA INFILE '/db_backups/customer.dat' INTO TABLE customer; Query OK, 8 rows affected (0.01 sec) Records: 8  Deleted: 0  Skipped: 0  Warnings: 0

And to restore it on Windows, use:

mysql> LOAD DATA INFILE 'c:\\db_backups\\customer.dat' INTO TABLE customer; Query OK, 8 rows affected (0.01 sec) Records: 8  Deleted: 0  Skipped: 0  Warnings: 0

As you can see, the data has been successfully restored:

mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | | 10 | Breyton    | Tshabalala  | B       | +----+------------+-------------+---------+ 8 rows in set (0.00 sec)

What If Something Goes Wrong?

Something can go wrong for a number of reasons:

  • If you're trying unsuccessfully to use LOAD DATA, perhaps you don't have permission to read a file on the server. The user doing the LOAD DATA needs to have the FILE privilege (see Chapter 14, "Database Security"), and the file needs to either exist in the database directory or be readable by all.

  • A common mistake is not to match the terminators and enclosure characters. They must be exactly the same as they are in the data file (or were specified in the SELECT INTO statement). If not, the result is that everything seems to work, but the table remains blank or full of NULL values. See the next section for more information.

  • If you're using the LOCAL keyword, it will not work if MySQL has been started with the
    --local-infile=0 option (see Chapter 13, "Configuring and Optimizing MySQL").

  • The pathname or filename was not specified correctly (remember to use the escape character for Windows pathnames).

Using LOAD DATA with Options

Let's restore from some of the other backups, using some of the other options:

mysql> LOAD DATA INFILE '/db_backups/customer2.dat' INTO TABLE customer; Query OK, 8 rows affected (0.01 sec) Records: 8  Deleted: 0  Skipped: 0  Warnings: 32 

Although this seemed to work, it didn't restore the data correctly:

mysql> SELECT * FROM customer; +----+------------+---------+---------+ | id | first_name | surname | initial | +----+------------+---------+---------+ |  1 | NULL       | NULL    | NULL    | |  2 | NULL       | NULL    | NULL    | |  3 | NULL       | NULL    | NULL    | |  4 | NULL       | NULL    | NULL    | |  5 | NULL       | NULL    | NULL    | |  7 | NULL       | NULL    | NULL    | |  6 | NULL       | NULL    | NULL    | | 10 | NULL       | NULL    | NULL    | +----+------------+---------+---------+ 8 rows in set (0.00 sec)

The problem was that you did not match the terminators correctly. Remember that
customer2.dat was created with the FIELDS TERMINATED BY 'zz' option. So, you need to
restore it in the same way:

mysql> TRUNCATE customer; Query OK, 0 rows affected (0.00 sec) mysql> LOAD DATA INFILE '/db_backups/customer2.dat' INTO TABLE customer  FIELDS TERMINATED BY 'zz'; Query OK, 8 rows affected (0.01 sec) Records: 8  Deleted: 0  Skipped: 0  Warnings: 0 mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | | 10 | Breyton    | Tshabalala  | B       | +----+------------+-------------+---------+ 8 rows in set (0.00 sec) 

The same applies to the LINES TERMINATED BY clause used to create customer3.dat:

mysql> TRUNCATE customer; Query OK, 0 rows affected (0.00 sec) mysql> LOAD DATA INFILE '/db_backups/customer3.dat' INTO TABLE customer  FIELDS TERMINATED BY '|' LINES TERMINATED BY '[end]'; Query OK, 8 rows affected (0.00 sec) Records: 8  Deleted: 0  Skipped: 0  Warnings: 0 mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | | 10 | Breyton    | Tshabalala  | B       | +----+------------+-------------+---------+ 8 rows in set (0.00 sec)

The ENCLOSED BY clause also needs to be added if it has been used, as with customer4.dat:

mysql> TRUNCATE customer; Query OK, 0 rows affected (0.00 sec) mysql> LOAD DATA INFILE '/db_backups/customer4.dat' INTO TABLE customer  FIELDS TERMINATED BY '|' ENCLOSED BY '"' LINES TERMINATED BY '\n'; Query OK, 8 rows affected (0.01 sec) Records: 8  Deleted: 0  Skipped: 0  Warnings: 0 mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | | 10 | Breyton    | Tshabalala  | B       | +----+------------+-------------+---------+ 8 rows in set (0.00 sec) 

And of course the same applies to the OPTIONALLY ENCLOSED clause as well, used to create customer5.dat:

mysql> TRUNCATE customer; Query OK, 0 rows affected (0.00 sec) mysql> LOAD DATA INFILE '/db_backups/customer5.dat' INTO TABLE customer  FIELDS TERMINATED BY '|' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n'; Query OK, 8 rows affected (0.01 sec) Records: 8  Deleted: 0  Skipped: 0  Warnings: 0 mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | | 10 | Breyton    | Tshabalala  | B       | +----+------------+-------------+---------+ 8 rows in set (0.00 sec)

You can also update from the partially backed-up file, customer6.dat:

mysql> TRUNCATE customer; Query OK, 0 rows affected (0.00 sec) mysql> LOAD DATA INFILE '/db_backups/customer6.dat' INTO TABLE customer  FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n'; Query OK, 7 rows affected (0.01 sec) Records: 7  Deleted: 0  Skipped: 0  Warnings: 0 mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | +----+------------+-------------+---------+ 7 rows in set (0.00 sec)

What if you now realize you made a mistake and want to restore the entire table? If you immediately LOAD DATA from a file containing a full backup, you'd come across the following problem:

mysql> LOAD DATA INFILE '/db_backups/customer.dat' INTO     TABLE customer;        ERROR 1062: Duplicate entry '1'     for key 1                                      mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | +----+------------+-------------+---------+ 7 rows in set (0.00 sec) 

You've got a duplicate key error, and the file stopped processing at that point. You could of course simply clear the table beforehand, as you've been doing before all the restores to date, but if you were trying to restore a table that already contains records, you may not want to remove everything and start again. The two keywords that become useful here are REPLACE and IGNORE. The latter ignores any rows that duplicate an existing row on a unique index or primary key. So, as in this situation, IGNORE is useful where you know the records have not changed and you don't want to drop and restore all the records again:

mysql> LOAD DATA INFILE '/db_backups/customer.dat' IGNORE INTO TABLE customer; Query OK, 1 row affected (0.00 sec) Records: 8  Deleted: 0  Skipped: 7  Warnings: 0

You can see that of the eight rows, seven were skipped and only the missing record was inserted. On a large file this would save a lot of time and prevent the inconvenience of temporarily having no data available. All records are now present again:

mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | | 10 | Breyton    | Tshabalala  | B       | +----+------------+-------------+---------+ 8 rows in set (0.00 sec) 

The REPLACE keyword comes in useful where the values of the records have changed, and you want to restore the records existing on disk. To demonstrate, you'll make the far-too-common mistake of updating all records when you only mean to update one, accidentally changing all surnames to Fortune:

mysql> UPDATE customer SET surname='Fortune'; Query OK, 8 rows affected (0.00 sec) Rows matched: 8  Changed: 8  Warnings: 0

You realize your error after you check the table!

mysql> SELECT * FROM customer; +----+------------+---------+---------+ | id | first_name | surname | initial | +----+------------+---------+---------+ |  1 | Yvonne     | Fortune | X       | |  2 | Johnny     | Fortune | B       | |  3 | Winston    | Fortune | M       | |  4 | Patricia   | Fortune | C       | |  5 | Francois   | Fortune | P       | |  7 | Winnie     | Fortune | NULL    | |  6 | Neil       | Fortune | NULL    | | 10 | Breyton    | Fortune | B       | +----+------------+---------+---------+ 8 rows in set (0.00 sec)

Now, restore using the REPLACE keyword:

mysql> LOAD DATA INFILE '/db_backups/customer.dat' REPLACE INTO TABLE customer; Query OK, 16 rows affected (0.00 sec) Records: 8  Deleted: 8  Skipped: 0  Warnings: 0 mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | | 10 | Breyton    | Tshabalala  | B       | +----+------------+-------------+---------+ 8 rows in set (0.00 sec)

LOAD DATA LOCAL is an option that allows the contents of a file that exists on the MySQL client machine to be uploaded to the database server.

LOW PRIORITY causes the addition of the new records to wait until there are no other clients reading from a table (as it does with an ordinary INSERT).

The CONCURRENT keyword is a useful one if you still want the table to be read. It allows other threads to read from a MyISAM table (but slows the LOAD DATA process down).

Security Issues with LOAD DATA LOCAL

Restoring from a client machine may be convenient, but it does come with a security risk. Someone could use LOAD DATA LOCAL to read any files to which the user they are connecting as has access. They could do this by creating a table and reading from the table after they have loaded the data. If they were connecting as the same user as the web server and have the right access to run queries, this becomes dangerous. By default, MySQL allows LOAD DATA LOCAL. To prevent this and disallow all LOAD DATA LOCAL, start the MySQL server with the --local-infile=0 option. You could also compile MySQL without the --enable-local-infile option.

Using mysqlimport Instead of LOAD DATA

Instead of LOAD DATA, which is run from inside MySQL, you can use the command-line equivalent, mysqlimport. The syntax is as follows:

% mysqlimport [options] databasename filename1 [filename2 ...]

Many of the options are the same as the LOAD DATA equivalents. The table to import the data into is determined from the filename. To do this, mysqlimport drops the extension of the filename, so customer.dat is imported into the customer table.

Use mysqlimport to restore the customer data, as follows:

mysql> SELECT * FROM customer;  +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | | 10 | Breyton    | Tshabalala  | B       | +----+------------+-------------+---------+ 8 rows in set (0.00 sec) mysql> TRUNCATE customer; Query OK, 0 rows affected (0.01 sec) mysql> exit Bye % mysqlimport firstdb /db_backups/customer.dat firstdb.customer: Records: 8  Deleted: 0  Skipped: 0  Warnings: 0 [root@test data]# mysql firstdb; Welcome to the MySQL monitor.  Commands end with ; or \g. Your MySQL connection id is 7 to server version: 4.0.1-alpha-max-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> SELECT * FROM customer; +----+------------+-------------+---------+ | id | first_name | surname     | initial | +----+------------+-------------+---------+ |  1 | Yvonne     | Clegg       | X       | |  2 | Johnny     | Chaka-Chaka | B       | |  3 | Winston    | Powers      | M       | |  4 | Patricia   | Mankunku    | C       | |  5 | Francois   | Papo        | P       | |  7 | Winnie     | Dlamini     | NULL    | |  6 | Neil       | Beneke      | NULL    | | 10 | Breyton    | Tshabalala  | B       | +----+------------+-------------+---------+ 8 rows in set (0.00 sec) 

And the data is restored.

Table 11.2 describes the options available to mysqlimport.

Table 11.2: mysqlimport Options

Option

Description

-c, --columns=...

Takes a comma-separated list of field names as an argument. These are used to create a LOAD DATA INFILE command.

--character-sets-dir=name

Tells MySQL the directory where the character sets are.

-C, --compress

Compresses the data transferred between the client and server if both support compression.

-#, --debug[=option_string]

Traces program usage for debugging purposes.

-d, --delete

Empties the table before importing the text file.

--fields-terminated-by=...

Same as the LOAD DATA INFILE option.

--fields-enclosed-by=...

Same as the LOAD DATA INFILE option.

--fields-optionally-enclosed-by=...

Same as the LOAD DATA INFILE option.

--fields-escaped-by=...

Same as the LOAD DATA INFILE option.

--lines-terminated-by=...

Same as the LOAD DATA INFILE option.

-f, --force

Continues even if there are MySQL errors during the dump.

--help

Displays a help message and exits.

-h host_name, --host= host_name

Imports data to the MySQL server found on the named host. The default host is localhost.

-i, --ignore

Added records that would cause a duplicate key error are ignored. Usually they result in an error and cause the process to stop at that point.

-l, --lock-tables

Locks all tables for writing before processing any text files, which keeps the tables synchronized on the server.

-L, --local

Reads input files from the client machine. If you connect to localhost (the default), text files are assumed to be on the server.

-ppassphrase, --password[=passphrase]

Specifies the password to use when connecting to the server. As usual, if you don't specify the password, you will be prompted for it, which is a safer option.

-P portnumber, --port=portnumber

Specifies the TCP/IP port number to use when connecting to the host. This does not apply in the case of connections to localhost. See the -S option.

-r, --replace

A record to be added that would result in a duplicate key replaces the original record of that same key. Usually this results in an error and causes the process to stop at that point.

-s, --silent

Displays output only when errors occur.

-S /path/to/socket, --socket=/path/to/socket

Specifies the socket file to use when connecting to localhost (the default).

-u username, --user=username

Specifies the MySQL username to use when connecting to the server. The default value is your Unix login name.

-v, --verbose

Displays more information during the run.

-V, --version

Displays version information and exits.



Mastering MySQL 4
Mastering MySQL 4
ISBN: 0782141625
EAN: 2147483647
Year: 2003
Pages: 230
Authors: Ian Gilfillan

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net