El número de la versión de la distribución de MySQL que usa (por ejemplo, MySQL 4.0.12). Puede consultar la versión que está usando ejecuntado mysqladmin version. El programa mysqladmin puede encontrarse en el directorio bin bajo el directorio de instalación.

El fabricante y modelo de la máquina en la que experimenta el problema.

Nombre del sistema operativo y versión. Si trabaja con Windows, puede obtener el nombre y número de versión haciendo doble click en el icono Mi PC y consultando el menú "Ayuda/Acerca de Windows". Para la mayoría de sistemas Unix puede obtener esta información con el comando uname -a.

En ocasiones la cantidad de memoria (real y virtual) es relevante. Si lo duda, incluya estos valores.

Si usa una distribución fuente del software MySQL, el nombre y número de versión del compilador usado es necesario.Si usa una distribución binaria, necesita el nombre de la distribución.

Si el problema ocurre durante la compilación, incluya el mensaje de error exacto y unas cuantas líneas de contexto alrededor del código en el fichero donde ocurre el error.

Si mysqld cae, incluya la consulta que hizo caer mysqld. Normalmente puede consultarlo ejecutando mysqld con el log de consultas activado, y luego consultando el log tras la caída de mysqld. Consulte Sección D.1.5, “El uso de registros (logs) para encontrar la causa de errores de mysqld”.

Si una base de datos está relacionada con el problema, incluya la salida del comando mysqldump --no-data db_name tbl_name. Este es un método sencillo y poderoso para obtener información acerca de cualquier tabla en una base de datos. La información nos ayuda a crear una situación similar a la que ha provocado el fallo.

Para bugs relacionados con rendimiento o problemas con consultas SELECT, siempre debe incluir la salida de EXPLAIN SELECT ..., y como mínimo el número de filas que el comando SELECT produce. También puede incluir la salida de SHOW CREATE TABLE tbl_name para cada tabla implicada. Mientras más información tengamos acerca de la situación, es más posible que podamos ayudar..

El siguiente es un ejemplo de un reporte muy bueno. Debe ser posteado con el script mysqlbug. El ejemplo usa la herramienta por líneas de comando mysql. Tenga en cuenta el terminador de comandos \G para comandos cuya salida exceda las de un monitor de 80 columnas.

mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
       <salida de SHOW COLUMNS>
mysql> EXPLAIN SELECT ...\G
       <salida de EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...;
       <Una pequeña descripción de la salida del SELECT,
       incluyendo el tiempo empleado en ejecutar la consulta>
mysql> SHOW STATUS;
       <salida de SHOW STATUS>

Si ocurre un problema al ejecutar mysqld, trate de proporcionar un script de entrada que reproduzca la anomalía. Este script debe incluir cualquier fichero fuente necesario. Mientras más fielmente reproduzca el script la situación, mejor. Si puede hacer un caso de test reproducible, debe postearlo en http://bugs.mysql.com/ para un tratamiento prioritario.

Si no puede proporcionar un script, debe como mínimo incluir la salida de mysqladmin variables extended-status processlist en su correo para proporcionar algo de información sobre cómo se está comportando el sistema.

Si no puede proporcionar un caso de test con unas pocas líneas, o si la tabla de test es demasiado grande para ser enviada a la lista de correo (más de 10 filas), debe dumpear sus tablas usando mysqldump y crear un ficero README que describa su problema.

Cree un fichero comprimido con sus ficheros usando tar y gzip o zip, y use FTP para transferir el archivo a ftp://ftp.mysql.com/pub/mysql/upload/. Después introduzca el problema en nuestra base de datos en http://bugs.mysql.com/.

Si cree que el servidor MySQL produce un resultado extraño de una consulta, incluya no sólo el resultado, sino también su opinión sobre cuál debería ser el resultado correcto, y una citación describiendo las bases de su opinión.

Cuando de un ejemplo del problema, es mejor usar los nombres de variables, de tablas, etc. que existan en la situación en lugar de usar nuevos nombres. El problema puede estar relacionado con el nombre de una variable o tabla. Estos casos son raros, pero es mejor estar seguro que arrepentirse luego. Después de todo, debería ser más fácil dar un ejemplo que use la situación real y esto es mejor para nosotros. En caso que tenga datos que no quiera enseñar, puede usar FTP para transferirlo a ftp://ftp.mysql.com/pub/mysql/upload/. Si la información es realmente secreta y no quiere enseñárnosla, entonces puede proporcionarnos un ejemplo usando otros nombres, pero por favor, considérelo como la última opción.

Incluya todas las opciones introducidas en los programas relevantes, si es posible. Por ejemplo, indique las opiones que usa cuando inicia el servidor mysqld así como las opciones que usa cuando ejecuta cualquier programa cliente MySQL. Las opciones de dichos programas, tales como mysqld y mysql, y al script configure , son a menudo claves para obtener una respuesta y muy relevantes. Nunca es mala idea incluirlas. Si usa cualquier módulo, como Perl o PHP, por favor incluya los número de versiones de los mismos también.

Si su pregunta está relacionada con el sistema de privilegios, por favor incluya la salida de mysqlaccess, la salida de mysqladmin reload, y todos los mensajes de error que obtenga cuando intente conectar. Cuando testee sus privilegios, debe ejecutar el comando mysqlaccess. Después, ejecute mysqladmin reload version y trate de conectar con el comando que le causa problemas. mysqlaccess se encuentra en el directorio bin bajo el directorio de instalación de MySQL.

Si tiene un parche para un bug, inclúyalo. Pero no asuma que el parche es todo lo que necesitamos o que podemos usarlo, sin proporcionar alguna información necesaria como casos de test mostrando el problema que corrige el parche. Podemos encontrar problemas en su parche o puede que no lo entendamos en absoluto; en ese caso no podemos usarlo.

Si no podemos verificar exactamente el propósito del parche, no lo usaremos. Los casos de test nos ayudan en este punto. Nos muestran que el parche puede tratar todas las situaciones que puedan ocurrir. Si encontramos un caso extremo (incluso uno raro) donde el parche no funcione, será inútil.

Suposiciones acerca de la naturaleza del bug, porqué ocurre o de qué depende, suelen ser incorrectas. Incluso el equipo de MySQL no puede adivinar estas cosas sin usar un debugger para determinar la causa real de un bug.

Indique en su reporte que ha chequeado el manual de referencia y el archivo de correo, de forma que otros sepan que ha intentado solucionar el problema por sí mismo.

Si obtiene un parse error, por favor chequee su sintaxis con cuidado. Si no puede encontrar nada incorrecto en ella, es muy posible que su versión de MySQL Server no soporte la sintaxis que utiliza. Si está usando la versión actual y el manual en http://dev.mysql.com/doc/ no cubre la versión que usa, MySQL Server no soporta su consulta. En ese caso, sus únicas opciones son implementar la sintaxis usted mismo o enviar un mail a <licensing@mysql.com> y pedir una oferta para implementarlo.

Si el manual cubre la sintaxis que está usando, pero tiene una versión más antigua de MySQL, compruebe el historial de cambios de MySQL para ver si la sintaxis ha sido implementada. En ese caso, tiene la opción de actualizar a una nueva versión de MySQL Server. Consulte Apéndice C, Historial de cambios de MySQL.

Si su problema es que los datos parecen estar corruptos u obtiene errores al acceder a una tabla en particular, debe chequear y tratar de arreglar las tablas con CHECK TABLE y REPAIR TABLE o con myisamchk. Consulte Capítulo 5, Administración de bases de datos.

Si está utilizando Windows, verifique que lower_case_table_names es 1 o 2 con SHOW VARIABLES LIKE 'lower_case_table_names'.

Si tiene problemas con tablas corruptas a menudo, debe tratar de encontrar cuándo y porqué ocurre. En este caso, el log de errores en el directorio de datos de MySQL puede contener información acerca de qué ha ocurrido. (Éste es el fichero con el sufijo .err en el nombre.) Consulte Sección 5.10.1, “El registro de errroes (Error Log)”. Por favor, incluya cualquier información relevante de este fichero en su reporte. Normalmente mysqld nunca debería corromper una tabla si nada muere durante una actualización. Si puede encontrar la causa de un mysqld muriendo, es mucho más fácil para nosotros encontrar una solución al problema. Consulte Sección A.1, “Cómo determinar a qué es debido un problema”.

Si es posible, descargue e instale la versión más reciente de MySQL Server y compruebe si resuelve su problema. Todas las versiones del software MySQL son testeadas duramente y deberían funcionar sin problemas. Creemos en hacer todo tan compatible con versiones anteriores como sea posible, y debería cambiar entre versiones de MySQL sin dificultades. Consulte Sección 2.1.2, “Escoger la distribución MySQL a instalar”.