This section provides information about techniques for more effective use of mysql and about mysql operational behavior.
Input-Line Editing
mysql supports input-line editing, which enables you to modify the current input line in place or recall previous input lines. For example, the left-arrow and right-arrow keys move horizontally within the current input line, and the up-arrow and down-arrow keys move up and down through the set of previously entered lines. Backspace deletes the character before the cursor and typing new characters enters them at the cursor position. To enter the line, press Enter.
        On Windows, the editing key sequences are the same as supported
        for command editing in console windows. On Unix, the key
        sequences depend on the input library used to build
        mysql (for example, the
        libedit or readline
        library).
      
        Documentation for the libedit and
        readline libraries is available online. To
        change the set of key sequences permitted by a given input
        library, define key bindings in the library startup file. This
        is a file in your home directory: .editrc
        for libedit and .inputrc
        for readline.
      
        For example, in libedit,
        Control+W deletes everything before the current
        cursor position and Control+U deletes the
        entire line. In readline,
        Control+W deletes the word before the cursor
        and Control+U deletes everything before the
        current cursor position. If mysql was built
        using libedit, a user who prefers the
        readline behavior for these two keys can put
        the following lines in the .editrc file
        (creating the file if necessary):
      
bind "^W" ed-delete-prev-word
bind "^U" vi-kill-line-prev
        To see the current set of key bindings, temporarily put a line
        that says only bind at the end of
        .editrc. mysql shows the
        bindings when it starts.
Disabling Interactive History
The up-arrow key enables you to recall input lines from current and previous sessions. In cases where a console is shared, this behavior may be unsuitable. mysql supports disabling the interactive history partially or fully, depending on the host platform.
        On Windows, the history is stored in memory.
        Alt+F7 deletes all input lines stored in memory
        for the current history buffer. It also deletes the list of
        sequential numbers in front of the input lines displayed with
        F7 and recalled (by number) with
        F9. New input lines entered after you press
        Alt+F7 repopulate the current history buffer.
        Clearing the buffer does not prevent logging to the Windows
        Event Viewer, if the --syslog
        option was used to start mysql. Closing the
        console window also clears the current history buffer.
      
        To disable interactive history on Unix, first delete the
        .mysql_history file, if it exists (previous
        entries are recalled otherwise). Then start
        mysql with the
        --histignore="*" option to ignore all new
        input lines. To re-enable the recall (and logging) behavior,
        restart mysql without the option.
      
        If you prevent the .mysql_history file from
        being created (see Controlling the History File)
        and use --histignore="*" to start the
        mysql client, the interactive history recall
        facility is disabled fully. Alternatively, if you omit the
        --histignore option, you can
        recall the input lines entered during the current session.
Unicode Support on Windows
        Windows provides APIs based on UTF-16LE for reading from and
        writing to the console; the mysql client for
        Windows is able to use these APIs. The Windows installer creates
        an item in the MySQL menu named MySQL command line
        client - Unicode. This item invokes the
        mysql client with properties set to
        communicate through the console to the MySQL server using
        Unicode.
      
To take advantage of this support manually, run mysql within a console that uses a compatible Unicode font and set the default character set to a Unicode character set that is supported for communication with the server:
- Open a console window. 
- Go to the console window properties, select the font tab, and choose Lucida Console or some other compatible Unicode font. This is necessary because console windows start by default using a DOS raster font that is inadequate for Unicode. 
- Execute mysql.exe with the - --default-character-set=utf8mb4(or- utf8mb3) option. This option is necessary because- utf16leis one of the character sets that cannot be used as the client character set. See Impermissible Client Character Sets.
With those changes, mysql uses the Windows APIs to communicate with the console using UTF-16LE, and communicate with the server using UTF-8. (The menu item mentioned previously sets the font and character set as just described.)
        To avoid those steps each time you run mysql,
        you can create a shortcut that invokes
        mysql.exe. The shortcut should set the
        console font to Lucida Console or some other compatible Unicode
        font, and pass the
        --default-character-set=utf8mb4
        (or utf8mb3) option to
        mysql.exe.
      
        Alternatively, create a shortcut that only sets the console
        font, and set the character set in the
        [mysql] group of your
        my.ini file:
      
[mysql]
default-character-set=utf8mb4   # or utf8mb3Displaying Query Results Vertically
Some query results are much more readable when displayed vertically, instead of in the usual horizontal table format. Queries can be displayed vertically by terminating the query with \G instead of a semicolon. For example, longer text values that include newlines often are much easier to read with vertical output:
mysql> SELECT * FROM mails WHERE LENGTH(txt) < 300 LIMIT 300,1\G
*************************** 1. row ***************************
  msg_nro: 3068
     date: 2000-03-01 23:29:50
time_zone: +0200
mail_from: Jones
    reply: jones@example.com
  mail_to: "John Smith" <smith@example.com>
      sbj: UTF-8
      txt: >>>>> "John" == John Smith writes:
John> Hi.  I think this is a good idea.  Is anyone familiar
John> with UTF-8 or Unicode? Otherwise, I'll put this on my
John> TODO list and see what happens.
Yes, please do that.
Regards,
Jones
     file: inbox-jani-1
     hash: 190402944
1 row in set (0.09 sec)Using Safe-Updates Mode (--safe-updates)
        For beginners, a useful startup option is
        --safe-updates (or
        --i-am-a-dummy,
        which has the same effect). Safe-updates mode is helpful for
        cases when you might have issued an
        UPDATE or
        DELETE statement but forgotten
        the WHERE clause indicating which rows to
        modify. Normally, such statements update or delete all rows in
        the table. With --safe-updates,
        you can modify rows only by specifying the key values that
        identify them, or a LIMIT clause, or both.
        This helps prevent accidents. Safe-updates mode also restricts
        SELECT statements that produce
        (or are estimated to produce) very large result sets.
      
        The --safe-updates option causes
        mysql to execute the following statement when
        it connects to the MySQL server, to set the session values of
        the sql_safe_updates,
        sql_select_limit, and
        max_join_size system variables:
      
SET sql_safe_updates=1, sql_select_limit=1000, max_join_size=1000000;
        The SET
        statement affects statement processing as follows:
- Enabling - sql_safe_updatescauses- UPDATEand- DELETEstatements to produce an error if they do not specify a key constraint in the- WHEREclause, or provide a- LIMITclause, or both. For example:- UPDATE tbl_name SET not_key_column=val WHERE key_column=val; UPDATE tbl_name SET not_key_column=val LIMIT 1;
- Setting - sql_select_limitto 1,000 causes the server to limit all- SELECTresult sets to 1,000 rows unless the statement includes a- LIMITclause.
- Setting - max_join_sizeto 1,000,000 causes multiple-table- SELECTstatements to produce an error if the server estimates it must examine more than 1,000,000 row combinations.
        To specify result set limits different from 1,000 and 1,000,000,
        you can override the defaults by using the
        --select-limit and
        --max-join-size options when you
        invoke mysql:
      
mysql --safe-updates --select-limit=500 --max-join-size=10000
        It is possible for UPDATE and
        DELETE statements to produce an
        error in safe-updates mode even with a key specified in the
        WHERE clause, if the optimizer decides not to
        use the index on the key column:
- Range access on the index cannot be used if memory usage exceeds that permitted by the - range_optimizer_max_mem_sizesystem variable. The optimizer then falls back to a table scan. See Limiting Memory Use for Range Optimization.
- If key comparisons require type conversion, the index may not be used (see Section 10.3.1, “How MySQL Uses Indexes”). Suppose that an indexed string column - c1is compared to a numeric value using- WHERE c1 = 2222. For such comparisons, the string value is converted to a number and the operands are compared numerically (see Section 14.3, “Type Conversion in Expression Evaluation”), preventing use of the index. If safe-updates mode is enabled, an error occurs.
These behaviors are included in safe-updates mode:
- EXPLAINwith- UPDATEand- DELETEstatements does not produce safe-updates errors. This enables use of- EXPLAINplus- SHOW WARNINGSto see why an index is not used, which can be helpful in cases such as when a- range_optimizer_max_mem_sizeviolation or type conversion occurs and the optimizer does not use an index even though a key column was specified in the- WHEREclause.
- When a safe-updates error occurs, the error message includes the first diagnostic that was produced, to provide information about the reason for failure. For example, the message may indicate that the - range_optimizer_max_mem_sizevalue was exceeded or type conversion occurred, either of which can preclude use of an index.
- For multiple-table deletes and updates, an error is produced with safe updates enabled only if any target table uses a table scan. 
Disabling mysql Auto-Reconnect
If the mysql client loses its connection to the server while sending a statement, it immediately and automatically tries to reconnect once to the server and send the statement again. However, even if mysql succeeds in reconnecting, your first connection has ended and all your previous session objects and settings are lost: temporary tables, the autocommit mode, and user-defined and session variables. Also, any current transaction rolls back. This behavior may be dangerous for you, as in the following example where the server was shut down and restarted between the first and second statements without you knowing it:
mysql> SET @a=1;
Query OK, 0 rows affected (0.05 sec)
mysql> INSERT INTO t VALUES(@a);
ERROR 2006: MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: test
Query OK, 1 row affected (1.30 sec)
mysql> SELECT * FROM t;
+------+
| a    |
+------+
| NULL |
+------+
1 row in set (0.05 sec)
        The @a user variable has been lost with the
        connection, and after the reconnection it is undefined. If it is
        important to have mysql terminate with an
        error if the connection has been lost, you can start the
        mysql client with the
        --skip-reconnect
        option.
      
For more information about auto-reconnect and its effect on state information when a reconnection occurs, see Automatic Reconnection Control.
mysql Client Parser Versus Server Parser
The mysql client uses a parser on the client side that is not a duplicate of the complete parser used by the mysqld server on the server side. This can lead to differences in treatment of certain constructs. Examples:
- The server parser treats strings delimited by - "characters as identifiers rather than as plain strings if the- ANSI_QUOTESSQL mode is enabled.- The mysql client parser does not take the - ANSI_QUOTESSQL mode into account. It treats strings delimited by- ",- ', and- `characters the same, regardless of whether- ANSI_QUOTESis enabled.
- Within - /*! ... */and- /*+ ... */comments, the mysql client parser interprets short-form mysql commands. The server parser does not interpret them because these commands have no meaning on the server side.- If it is desirable for mysql not to interpret short-form commands within comments, a partial workaround is to use the - --binary-modeoption, which causes all mysql commands to be disabled except- \Cand- \din noninteractive mode (for input piped to mysql or loaded using the- sourcecommand).