How to Report Bugs or Problems •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: •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. •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 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 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. 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. SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODE FROM INFORMATION_SCHEMA.TRIGGERS; SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE FROM INFORMATION_SCHEMA.ROUTINES; For triggers, you can use this statement: 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> 74