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. The change history (http://dev.mysql.com/doc/mysql/en/News.html) can be particularly useful since it is quite possible that a newer version already contains a solution to your problem.

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

Search the MySQL mailing list archives at http://lists.mysql.com/.

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

The version number of the MySQL distribution you are using (for example, MySQL 4.0.12). 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, the name and version number of the compiler used are needed. If you have a binary distribution, the distribution name is needed.

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 query that crashed mysqld. You can usually find this out by running mysqld with query logging enabled, and then looking in the log after mysqld crashes See the section called “Using Log Files to Find Cause of Errors in mysqld”.

If a database table is related to the problem, include the output from mysqldump --no-data db_name tbl_name. This is very easy to do and is a powerful way to get information about any table in a database. The information will help us create a situation matching the one you have.

For speed-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 involved table. The more information you give about your situation, the more likely it is that someone can help you.

The following is an example of a very good bug report. It should be posted with the mysqlbug script. The example uses the mysql command-line tool. Note the use of the \G statement terminator for statements whose output width would otherwise exceed that of an 80-column display device.

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 will reproduce 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 post it on http://bugs.mysql.com/ for high-priority treatment.

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

If you can't produce a test case with only a few rows, or if the test table is too big to be mailed to the mailing list (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, and use FTP to transfer the archive to ftp://ftp.mysql.com/pub/mysql/upload/. Then enter the problem into our bugs database at http://bugs.mysql.com/.

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

When giving an example of the problem, it's better to use the variable names, table names, and so on that exist in your actual situation than to come up with new names. The problem could be related to the name of a variable or table. 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. In case you have data that you don't want to show to others, you can use FTP to transfer it to ftp://ftp.mysql.com/pub/mysql/upload/. If the information is really top secret and you don't want to show it even to us, then 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 keys to answers and are very relevant. It is never a bad idea to include them. If you use any modules, such as Perl or PHP, please include the version numbers of those as well.

If your question is related to the privilege system, please include the output of mysqlaccess, the output of mysqladmin reload, and all the error messages you get when trying to connect. When you test your privileges, you should first run mysqlaccess. After this, execute mysqladmin reload version and try to connect with the program that gives you trouble. mysqlaccess can be found in the bin directory under your MySQL installation directory.

If you have a patch for a bug, do include it. But don't assume that the patch is all we need, or that we will use it, if you don't 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 can't use it.

If we can't verify exactly what the purpose of the patch is, we won't use it. Test cases will help us here. Show that the patch will handle all the situations that may occur. If we find a borderline case (even a rare one) where the patch won't 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 can't 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 you get a parse error, please check your syntax closely. If you can't find something wrong with it, it's 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 at http://dev.mysql.com/doc/ doesn't cover the syntax you are using, MySQL Server doesn't support your query. In this case, your only options are to implement the syntax yourself or email mailto:licensing@@mysql.com and ask for an offer to implement it.

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. See Appendix C, MySQL Change History.

If your problem is that your data appears corrupt or you get errors when you access a particular table, you should first check and then try to repair your tables with CHECK TABLE and REPAIR TABLE or with myisamchk. See Chapter 5, Database Administration.

If you are running Windows, please verify that lower_case_table_names is 1 or 2 with SHOW VARIABLES LIKE 'lower_case_table_names'.

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 the section called “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's much easier for us to provide you with a fix for the problem. See the section called “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 the section called “Choosing Which MySQL Distribution to Install”.