Chapter 1 General Information

Text in this style is used for SQL statements; database, table, and column names; program listings and source code; and environment variables. Example: “To reload the grant tables, use the FLUSH PRIVILEGES statement.”

Text in this style indicates input that you type in examples.

Text in this style indicates the names of executable programs and scripts, examples being mysql (the MySQL command-line client program) and mysqld (the MySQL server executable).

Text in this style is used for variable input for which you should substitute a value of your own choosing.

Text in this style is used for emphasis.

Text in this style is used in table headings and to convey especially strong emphasis.

Text in this style is used to indicate a program option that affects how the program is executed, or that supplies information that is needed for the program to function in a certain way. Example: “The --host option (short form -h) tells the mysql client program the hostname or IP address of the MySQL server that it should connect to”.

File names and directory names are written like this: “The global my.cnf file is located in the /etc directory.”

Character sequences are written like this: “To specify a wildcard, use the ‘%’ character.”

Added Features

Deprecated Features

Removed Features

Security improvements.  These security enhancements were added:

SQL mode changes.  Strict SQL mode for transactional storage engines (STRICT_TRANS_TABLES) is now enabled by default.

Implementation for the ONLY_FULL_GROUP_BY SQL mode has been made more sophisticated, to no longer reject deterministic queries that previously were rejected. In consequence, this mode is now enabled by default, to prohibit only nondeterministic queries containing expressions not guaranteed to be uniquely determined within a group.

The ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes are now deprecated but enabled by default. The long term plan is to have them included in strict SQL mode and to remove them as explicit modes in a future MySQL release. See SQL Mode Changes in MySQL 5.7.

The changes to the default SQL mode result in a default sql_mode system variable value with these modes enabled: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, and NO_ENGINE_SUBSTITUTION.

Online ALTER TABLE.  ALTER TABLE now supports a RENAME INDEX clause that renames an index. The change is made in place without a table-copy operation. It works for all storage engines. See Section 14.1.8, “ALTER TABLE Syntax”.

ngram and MeCab full-text parser plugins.  As of MySQL 5.7.6, MySQL provides a built-in full-text ngram parser plugin that supports Chinese, Japanese, and Korean (CJK), and an installable MeCab full-text parser plugin for Japanese.

For more information, see Section 13.9.8, “ngram Full-Text Parser”, and Section 13.9.9, “MeCab Full-Text Parser Plugin”.

InnoDB enhancements.  These InnoDB enhancements were added:

JSON support.  Beginning with MySQL 5.7.8, MySQL supports a native JSON type. JSON values are not stored as strings, instead using an internal binary format that permits quick read access to document elements. JSON documents stored in JSON columns are automatically validated whenever they are inserted or updated, with an invalid document producing an error. JSON documents are normalized on creation, and can be compared using most comparison operators such as =, <, <=, >, >=, <>, !=, and <=>; for information about supported operators as well as precedence and other rules that MySQL follows when comparing JSON values, see Comparison and Ordering of JSON Values.

MySQL 5.7.8 also introduces a number of functions for working with JSON values. These functions include those listed here:

In MySQL 5.7.9 and later, you can use column->path as shorthand for JSON_EXTRACT(column, path). This works as an alias for a column wherever a column identifier can occur in an SQL statement, including WHERE, ORDER BY, and GROUP BY clauses. This includes SELECT, UPDATE, DELETE, CREATE TABLE, and other SQL statements. The left hand side must be a JSON column identifier (and not an alias). The right hand side is a quoted JSON path expression which is evaluated against the JSON document returned as the column value.

See Section 13.16.3, “Functions That Search JSON Values”, for more information about -> and JSON_EXTRACT(). For information about JSON path support in MySQL 5.7, see Searching and Modifying JSON Values. See also Section 14.1.18.6, “Secondary Indexes and Generated Virtual Columns”.

System and status variables.  System and status variable information is now available in Performance Schema tables, in preference to use of INFORMATION_SCHEMA tables to obtain these variable. This also affects the operation of the SHOW VARIABLES and SHOW STATUS statements. The value of the show_compatibility_56 system variable affects the output produced from and privileges required for system and status variable statements and tables. For details, see the description of that variable in Section 6.1.4, “Server System Variables”.

sys schema.  MySQL distributions now include the sys schema, which is a set of objects that help DBAs and developers interpret data collected by the Performance Schema. sys schema objects can be used for typical tuning and diagnosis use cases. For more information, see Chapter 24, MySQL sys Schema.

Condition handling.  MySQL now supports stacked diagnostics areas. When the diagnostics area stack is pushed, the first (current) diagnostics area becomes the second (stacked) diagnostics area and a new current diagnostics area is created as a copy of it. Within a condition handler, executed statements modify the new current diagnostics area, but GET STACKED DIAGNOSTICS can be used to inspect the stacked diagnostics area to obtain information about the condition that caused the handler to activate, independent of current conditions within the handler itself. (Previously, there was a single diagnostics area. To inspect handler-activating conditions within a handler, it was necessary to check this diagnostics area before executing any statements that could change it.) See Section 14.6.7.3, “GET DIAGNOSTICS Syntax”, and Section 14.6.7.7, “The MySQL Diagnostics Area”.

Optimizer.  These optimizer enhancements were added:

Triggers.  Previously, a table could have at most one trigger for each combination of trigger event (INSERT, UPDATE, DELETE) and action time (BEFORE, AFTER). This limitation has been lifted and multiple triggers are permitted. For more information, see Section 21.3, “Using Triggers”.

Logging.  These logging enhancements were added:

Generated Columns.  MySQL now supports the specification of generated columns in CREATE TABLE and ALTER TABLE statements. Values of a generated column are computed from an expression specified at column creation time. Generated columns can be virtual (computed “on the fly” when rows are read) or stored (computed when rows are inserted or updated). For more information, see Section 14.1.18.5, “CREATE TABLE and Generated Columns”.

mysql client.  Previously, Control+C in mysql interrupted the current statement if there was one, or exited mysql if not. Now Control+C interrupts the current statement if there was one, or cancels any partial input line otherwise, but does not exit.

Database name rewriting with mysqlbinlog.  Renaming of databases by mysqlbinlog when reading from binary logs written using the row-based format is now supported using the --rewrite-db option added in MySQL 5.7.1.

This option uses the format --rewrite-db='dboldname->dbnewname'. You can implement multiple rewrite rules, by specifying the option multiple times.

HANDLER with partitioned tables.  The HANDLER statement may now be used with user-partitioned tables. Such tables may use any of the available partitioning types (see Section 20.2, “Partitioning Types”).

Index condition pushdown support for partitioned tables.  In MySQL 5.7.3 and later, queries on partitioned tables using the InnoDB or MyISAM storage engine may employ the index condition pushdown optimization that was introduced in MySQL 5.6. See Section 9.2.1.6, “Index Condition Pushdown Optimization”, for more information.

WITHOUT VALIDATION support for ALTER TABLE ... EXCHANGE PARTITION.  As of MySQL 5.7.5, ALTER TABLE ... EXCHANGE PARTITION syntax includes an optional {WITH|WITHOUT} VALIDATION clause. When WITHOUT VALIDATION is specified, ALTER TABLE ... EXCHANGE PARTITION does not perform row-by-row validation when exchanging a populated table with the partition, permitting database administrators to assume responsibility for ensuring that rows are within the boundaries of the partition definition. WITH VALIDATION is the default behavior and need not be specified explicitly. For more information, see Section 20.3.3, “Exchanging Partitions and Subpartitions with Tables”.

Master dump thread improvements.  The master dump thread was refactored to reduce lock contention and improve master throughput. Previous to MySQL 5.7.2, the dump thread took a lock on the binary log whenever reading an event; in MySQL 5.7.2 and later, this lock is held only while reading the position at the end of the last successfully written event. This means both that multiple dump threads are now able to read concurrently from the binary log file, and that dump threads are now able to read while clients are writing to the binary log.

Globalization improvements.  MySQL 5.7.4 includes a gb18030 character set that supports the China National Standard GB18030 character set. For more information about MySQL character set support, see Section 11.1, “Character Set Support”.

Changing the replication master without STOP SLAVE.  In MySQL 5.7.4 and later, the strict requirement to execute STOP SLAVE prior to issuing any CHANGE MASTER TO statement is removed. Instead of depending on whether the slave is stopped, the behavior of CHANGE MASTER TO now depends on the states of the slave SQL thread and slave I/O threads; which of these threads is stopped or running now determines the options that can or cannot be used with a CHANGE MASTER TO statement at a given point in time. The rules for making this determination are listed here:

You can check the current state of the slave SQL and I/O threads using SHOW SLAVE STATUS.

If you are using statement-based replication and temporary tables, it is possible for a CHANGE MASTER TO statement following a STOP SLAVE statement to leave behind temporary tables on the slave. As part of this set of improvements, a warning is now issued whenever CHANGE MASTER TO is issued following STOP SLAVE when statement-based replication is in use and Slave_open_temp_tables remains greater than 0.

For more information, see Section 14.4.2.1, “CHANGE MASTER TO Syntax”, and Section 18.3.7, “Switching Masters During Failover”.

Test suite.  The MySQL test suite now uses InnoDB as the default storage engine.

Multi-source replication is now possible.  MySQL Multi-Source Replication adds the ability to replicate from multiple masters to a slave. MySQL Multi-Source Replication topologies can be used to back up multiple servers to a single server, to merge table shards, and consolidate data from multiple servers to a single server. See Section 18.1.4, “MySQL Multi-Source Replication”.

As part of MySQL Multi-Source Replication, replication channels have been added. Replication channels enable a slave to open multiple connections to replicate from, with each channel being a connection to a master. See Section 18.2.3, “Replication Channels”.

Group Replication Performance Schema tables.  MySQL 5.7 adds a number of new tables to the Performance Schema to provide information about replication groups and channels. These include the following tables:

All of these tables were added in MySQL 5.7.2, except for replication_group_members and replication_group_member_stats, which were added in MySQL 5.7.6. For more information, see Section 23.9.11, “Performance Schema Replication Tables”.

Group Replication SQL.  The following statements were added in MySQL 5.7.6 for controlling group replication:

For more information, see Section 14.4.3, “SQL Statements for Controlling Group Replication”.

The ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes are now deprecated but enabled by default. The long term plan is to have them included in strict SQL mode and to remove them as explicit modes in a future MySQL release.

The deprecated ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes are still recognized so that statements that name them do not produce an error, but will be removed in a future version of MySQL. To make advance preparation for versions of MySQL in which these mode names do not exist, applications should be modified to not refer to them. See SQL Mode Changes in MySQL 5.7.

Changes to account-management statements make the following features obsolete. They are now deprecated:

Relying on implicit GROUP BY sorting in MySQL 5.7 is deprecated. To achieve a specific sort order of grouped results, it is preferable to use an explicit ORDER BY clause. GROUP BY sorting is a MySQL extension that may change in a future release; for example, to make it possible for the optimizer to order groupings in whatever manner it deems most efficient and to avoid the sorting overhead.

The EXTENDED and PARTITIONS keywords for the EXPLAIN statement are deprecated. These keywords are still recognized but are now unnecessary because their effect is always enabled.

The --skip-innodb option and its synonyms (--innodb=OFF, --disable-innodb, and so forth) are deprecated. These options have no effect as of MySQL 5.7. because InnoDB cannot be disabled.

The client-side --ssl and --ssl-verify-server-cert options are deprecated. Use --ssl-mode=REQUIRED instead of --ssl=1 or --enable-ssl. Use --ssl-mode=DISABLED instead of --ssl=0, --skip-ssl, or --disable-ssl. Use --ssl-mode=VERIFY_IDENTITY instead of --ssl-verify-server-cert options. (The server-side --ssl option is not deprecated.)

For the C API, MYSQL_OPT_SSL_ENFORCE and MYSQL_OPT_SSL_VERIFY_SERVER_CERT options for mysql_options() correspond to the client-side --ssl and --ssl-verify-server-cert options and are deprecated. Use MYSQL_OPT_SSL_MODE with an option value of SSL_MODE_REQUIRED or SSL_MODE_VERIFY_IDENTITY instead.

The log_warnings system variable and --log-warnings server option are deprecated. Use the log_error_verbosity system variable instead.

The binlog_max_flush_queue_time system variable does nothing in MySQL 5.7, and is deprecated as of MySQL 5.7.9.

The innodb_support_xa system variable, which enables InnoDB support for two-phase commit in XA transactions, is deprecated as of MySQL 5.7.10. InnoDB support for two-phase commit in XA transactions is always enabled as of MySQL 5.7.10.

The metadata_locks_cache_size and metadata_locks_hash_instances system variables are deprecated. These do nothing as of MySQL 5.7.4.

The sync_frm system variable is deprecated.

The global character_set_database and collation_database system variables are deprecated and will be removed in a future version of MySQL.

Assigning a value to the session character_set_database and collation_database system variables is deprecated and assignments produce a warning. The session variables will become read only in a future version of MySQL and assignments will produce an error. It will remain possible to access the session variables to determine the database character set and collation for the default database.

The ENCRYPT(), ENCODE(), DECODE(), DES_ENCRYPT(), and DES_DECRYPT() encryption functions are deprecated. Consider using AES_ENCRYPT() and AES_DECRYPT() instead.

The MBREqual() spatial function is deprecated. Use MBREquals() instead.

The INFORMATION_SCHEMA.PROFILING table is deprecated. Use the Performance Schema instead; see Chapter 23, MySQL Performance Schema.

mysqld_safe support for syslog output is deprecated. Use the native server syslog support used instead. See Section 6.4.2, “The Error Log”.

Conversion of pre-MySQL 5.1 database names containing special characters to 5.1 format with the addition of a #mysql50# prefix is deprecated. Because of this, the --fix-db-names and --fix-table-names options for mysqlcheck and the UPGRADE DATA DIRECTORY NAME clause for the ALTER DATABASE statement are also deprecated.

Upgrades are supported only from one release series to another (for example, 5.0 to 5.1, or 5.1 to 5.5), so there should be little remaining need for conversion of older 5.0 database names to current versions of MySQL. As a workaround, upgrade a MySQL 5.0 installation to MySQL 5.1 before upgrading to a more recent release.

mysql_install_db functionality has been integrated into the MySQL server, mysqld. To use this capability to initialize a MySQL installation, if you previously invoked mysql_install_db manually, invoke mysqld with the --initialize or --initialize-insecure option, depending on whether you want the server to generate a random password for the initial 'root'@'localhost' account.

mysql_install_db is now deprecated, as is the special --bootstrap option that mysql_install_db passes to mysqld.

The mysql_plugin utility is deprecated. Alternatives include loading plugins at server startup using the --plugin-load or --plugin-load-add option, or at runtime using the INSTALL PLUGIN statement.

The mysql_kill(), mysql_list_fields(), mysql_list_processes(), and mysql_refresh() C API functions are deprecated. The same is true of the corresponding COM_PROCESS_KILL, COM_FIELD_LIST, COM_PROCESS_INFO, and COM_REFRESH client/server protocol commands. Instead, use mysql_query() to execute a KILL, SHOW COLUMNS, SHOW PROCESSLIST, or FLUSH statement, respectively.

Support for passwords that use the older pre-4.1 password hashing format is removed, which involves the following changes. Applications that use any feature no longer supported must be modified.

In MySQL 5.6.6, the YEAR(2) data type was deprecated. Support for YEAR(2) is now removed. Once you upgrade to MySQL 5.7.5 or higher, any remaining YEAR(2) columns must be converted to YEAR(4) to become usable again. For conversion strategies, see Section 12.3.4, “YEAR(2) Limitations and Migrating to YEAR(4)”. For example, run mysql_upgrade after upgrading.

The innodb_mirrored_log_groups system variable. The only supported value was 1, so it had no purpose.

The storage_engine system variable. Use default_storage_engine instead.

The thread_concurrency system variable.

The timed_mutexes system variable. It does nothing and has no effect.

The IGNORE clause for ALTER TABLE.

INSERT DELAYED is no longer supported. The server recognizes but ignores the DELAYED keyword, handles the insert as a nondelayed insert, and generates an ER_WARN_LEGACY_SYNTAX_CONVERTED warning. (“INSERT DELAYED is no longer supported. The statement was converted to INSERT.”) Similarly, REPLACE DELAYED is handled as a nondelayed replace. The DELAYED keyword will be removed in a future release.

In addition, several DELAYED-related options or features were removed:

Database symlinking on Windows using for .sym files has been removed because it is redundant with native symlink support available using mklink. Any .sym file symbolic links will be ignored and should be replaced with symlinks created using mklink. See Section 9.12.4.3, “Using Symbolic Links for Databases on Windows”.

The unused --basedir, --datadir, and --tmpdir options for mysql_upgrade were removed.

Previously, program options could be specified in full or as any unambiguous prefix. For example, the --compress option could be given to mysqldump as --compr, but not as --comp because the latter is ambiguous. Option prefixes are no longer supported; only full options are accepted. This is because prefixes can cause problems when new options are implemented for programs and a prefix that is currently unambiguous might become ambiguous in the future. Some implications of this change:

SHOW ENGINE INNODB MUTEX output is removed in MySQL 5.7.2. Comparable information can be generated by creating views on Performance Schema tables.

The InnoDB Tablespace Monitor and InnoDB Table Monitor are removed in MySQL 5.7.4. For the Tablespace Monitor, equivalent functionality will be introduced before the GA release of MySQL 5.7. For the Table Monitor, equivalent information can be obtained from InnoDB INFORMATION_SCHEMA tables.

The specially named tables used to enable and disable the standard InnoDB Monitor and InnoDB Lock Monitor (innodb_monitor and innodb_lock_monitor) are removed in MySQL 5.7.4 and replaced by two dynamic system variables: innodb_status_output and innodb_status_output_locks. For additional information, see Section 15.15, “InnoDB Monitors”.

The innodb_use_sys_malloc and innodb_additional_mem_pool_size system variables, which were deprecated in MySQL 5.6.3, are removed in MySQL 5.7.4.

The msql2mysql, mysql_convert_table_format, mysql_find_rows, mysql_fix_extensions, mysql_setpermission, mysql_waitpid, mysql_zap, mysqlaccess, and mysqlbug utilities.

The mysqlhotcopy utility. Alternatives include mysqldump and MySQL Enterprise Backup.

The binary-configure.sh script.

The INNODB_PAGE_ATOMIC_REF_COUNT CMake option is removed in MySQL 5.7.5.

The innodb_create_intrinsic option is removed in MySQL 5.7.6.

The innodb_optimize_point_storage option and related internal data types (DATA_POINT and DATA_VAR_POINT) were removed.

The innodb_log_checksum_algorithm option is removed in MySQL 5.7.9.

Server/General

InnoDB Storage Engine

Replication and Binary Logging

Performance Schema

Start by searching the MySQL online manual at http://dev.mysql.com/doc/. We try to keep the manual up to date by updating it frequently with solutions to newly found problems. In addition, the release notes accompanying the manual can be particularly useful since it is quite possible that a newer version contains a solution to your problem. The release notes are available at the location just given for the manual.

If you get a parse error for an SQL statement, please check your syntax closely. If you cannot find something wrong with it, it is extremely likely that your current version of MySQL Server doesn't support the syntax you are using. If you are using the current version and the manual doesn't cover the syntax that you are using, MySQL Server doesn't support your statement.

If the manual covers the syntax you are using, but you have an older version of MySQL Server, you should check the MySQL change history to see when the syntax was implemented. In this case, you have the option of upgrading to a newer version of MySQL Server.

For solutions to some common problems, see Section B.5, “Problems and Common Errors”.

Search the bugs database at http://bugs.mysql.com/ to see whether the bug has been reported and fixed.

Search the MySQL mailing list archives at http://lists.mysql.com/. See Section 1.6.1, “MySQL Mailing Lists”.

You can also use http://www.mysql.com/search/ to search all the Web pages (including the manual) that are located at the MySQL Web site.

The version number of the MySQL distribution you are using (for example, MySQL 5.7.10). You can find out which version you are running by executing mysqladmin version. The mysqladmin program can be found in the bin directory under your MySQL installation directory.

The manufacturer and model of the machine on which you experience the problem.

The operating system name and version. If you work with Windows, you can usually get the name and version number by double-clicking your My Computer icon and pulling down the “Help/About Windows” menu. For most Unix-like operating systems, you can get this information by executing the command uname -a.

Sometimes the amount of memory (real and virtual) is relevant. If in doubt, include these values.

If you are using a source distribution of the MySQL software, include the name and version number of the compiler that you used. If you have a binary distribution, include the distribution name.

If the problem occurs during compilation, include the exact error messages and also a few lines of context around the offending code in the file where the error occurs.

If mysqld died, you should also report the statement that crashed mysqld. You can usually get this information by running mysqld with query logging enabled, and then looking in the log after mysqld crashes. See Section 26.5, “Debugging and Porting MySQL”.

If a database table is related to the problem, include the output from the SHOW CREATE TABLE db_name.tbl_name statement in the bug report. This is a very easy way to get the definition of any table in a database. The information helps us create a situation matching the one that you have experienced.

The SQL mode in effect when the problem occurred can be significant, so please report the value of the sql_mode system variable. For stored procedure, stored function, and trigger objects, the relevant sql_mode value is the one in effect when the object was created. For a stored procedure or function, the SHOW CREATE PROCEDURE or SHOW CREATE FUNCTION statement shows the relevant SQL mode, or you can query INFORMATION_SCHEMA for the information:

SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE
FROM INFORMATION_SCHEMA.ROUTINES;

For triggers, you can use this statement:

SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODE
FROM INFORMATION_SCHEMA.TRIGGERS;

For performance-related bugs or problems with SELECT statements, you should always include the output of EXPLAIN SELECT ..., and at least the number of rows that the SELECT statement produces. You should also include the output from SHOW CREATE TABLE tbl_name for each table that is involved. The more information you provide about your situation, the more likely it is that someone can help you.

The following is an example of a very good bug report. The statements are run using the mysql command-line tool. Note the use of the \G statement terminator for statements that would otherwise provide very long output lines that are difficult to read.

mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
       <output from SHOW COLUMNS>
mysql> EXPLAIN SELECT ...\G
       <output from EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...;
       <A short version of the output from SELECT,
       including the time taken to run the query>
mysql> SHOW STATUS;
       <output from SHOW STATUS>

If a bug or problem occurs while running mysqld, try to provide an input script that reproduces the anomaly. This script should include any necessary source files. The more closely the script can reproduce your situation, the better. If you can make a reproducible test case, you should upload it to be attached to the bug report.

If you cannot provide a script, you should at least include the output from mysqladmin variables extended-status processlist in your report to provide some information on how your system is performing.

If you cannot produce a test case with only a few rows, or if the test table is too big to be included in the bug report (more than 10 rows), you should dump your tables using mysqldump and create a README file that describes your problem. Create a compressed archive of your files using tar and gzip or zip. After you initiate a bug report for our bugs database at http://bugs.mysql.com/, click the Files tab in the bug report for instructions on uploading the archive to the bugs database.

If you believe that the MySQL server produces a strange result from a statement, include not only the result, but also your opinion of what the result should be, and an explanation describing the basis for your opinion.

When you provide an example of the problem, it is better to use the table names, variable names, and so forth that exist in your actual situation than to come up with new names. The problem could be related to the name of a table or variable. These cases are rare, perhaps, but it is better to be safe than sorry. After all, it should be easier for you to provide an example that uses your actual situation, and it is by all means better for us. If you have data that you do not want to be visible to others in the bug report, you can upload it using the Files tab as previously described. If the information is really top secret and you do not want to show it even to us, go ahead and provide an example using other names, but please regard this as the last choice.

Include all the options given to the relevant programs, if possible. For example, indicate the options that you use when you start the mysqld server, as well as the options that you use to run any MySQL client programs. The options to programs such as mysqld and mysql, and to the configure script, are often key to resolving problems and are very relevant. It is never a bad idea to include them. If your problem involves a program written in a language such as Perl or PHP, please include the language processor's version number, as well as the version for any modules that the program uses. For example, if you have a Perl script that uses the DBI and DBD::mysql modules, include the version numbers for Perl, DBI, and DBD::mysql.

If your question is related to the privilege system, please include the output of mysqladmin reload, and all the error messages you get when trying to connect. When you test your privileges, you should execute mysqladmin reload version and try to connect with the program that gives you trouble.

If you have a patch for a bug, do include it. But do not assume that the patch is all we need, or that we can use it, if you do not provide some necessary information such as test cases showing the bug that your patch fixes. We might find problems with your patch or we might not understand it at all. If so, we cannot use it.

If we cannot verify the exact purpose of the patch, we will not use it. Test cases help us here. Show that the patch handles all the situations that may occur. If we find a borderline case (even a rare one) where the patch will not work, it may be useless.

Guesses about what the bug is, why it occurs, or what it depends on are usually wrong. Even the MySQL team cannot guess such things without first using a debugger to determine the real cause of a bug.

Indicate in your bug report that you have checked the reference manual and mail archive so that others know you have tried to solve the problem yourself.

If your data appears corrupt or you get errors when you access a particular table, first check your tables with CHECK TABLE. If that statement reports any errors:

If you are running Windows, please verify the value of lower_case_table_names using the SHOW VARIABLES LIKE 'lower_case_table_names' statement. This variable affects how the server handles lettercase of database and table names. Its effect for a given value should be as described in Section 10.2.2, “Identifier Case Sensitivity”.

If you often get corrupted tables, you should try to find out when and why this happens. In this case, the error log in the MySQL data directory may contain some information about what happened. (This is the file with the .err suffix in the name.) See Section 6.4.2, “The Error Log”. Please include any relevant information from this file in your bug report. Normally mysqld should never crash a table if nothing killed it in the middle of an update. If you can find the cause of mysqld dying, it is much easier for us to provide you with a fix for the problem. See Section B.5.1, “How to Determine What Is Causing a Problem”.

If possible, download and install the most recent version of MySQL Server and check whether it solves your problem. All versions of the MySQL software are thoroughly tested and should work without problems. We believe in making everything as backward-compatible as possible, and you should be able to switch MySQL versions without difficulty. See Section 2.1.1, “Which MySQL Version and Distribution to Install”.