Si compara un valor NULL con una subconsulta utilizando ALL/ANY/SOME y la subconsulta retorna un conjunto vacío, la comparación podría devolver el resultado no estándar de NULL en vez de TRUE o FALSE. Esto será arreglado en MySQL 5.1.

La optimización de las subconsultas para IN no es tan efectiva como para =.

Aún cuando utilice lower_case_table_names=2 (que permite a MySQL recordar la diferencia entre mayúsculas y minúsculas utilizada en los nombres de las bases de datos y las tablas), MySQL no la recuerda en los nombres de bases de datos al utilizar la función DATABASE() o en los diversos registro (en sistemas no sensibles a mayúsculas/minúsculas).

Eliminar una restricción de FOREIGN KEY no funciona en una replicación porque la restricción puede tener otro nombre en el esclavo.

REPLACE (y LOAD DATA con la opción REPLACE) no dispara a ON DELETE CASCADE.

DISTINCT con ORDER BY no funciona dentro de GROUP_CONCAT() si no utiliza todas y únicamente aquellas columnas que están en la lista de DISTINCT.

Si un usuario tiene una transacción ejecutándose durante mucho tiempo y otro usuario elimina una tabla que es actualizada durante la transacción, hay una pequeña posibilidad de que el registro binario contenga el comando DROP TABLE antes de que dicha tabla sea utilizada en la transacción. Planeamos arreglar esto haciendo que el comando DROP TABLE espera a que la tabla no sea utilizada en ninguna transacción.

Cuando se inserta un valor de entero grande (entre 2⁶³ y 2⁶⁴–1) en una columna decimal o de cadena de caracteres, se inserta con un valor negativo porque el número es evaluado en un contexto de entero con signo.

FLUSH TABLES WITH READ LOCK no bloquea los COMMIT si el servidor se está ejecutando sin registro binario, lo que puede causar un problema (de consistencia entre tablas) cuando se hace una copia de seguridad completa.

ANALYZE TABLE en una tabla BDB puede hacer que en algunos casos la tabla quede inutilizable hasta que reinicie mysqld. Si esto ocurre, busque los errores similares a este en el archivo de error de MySQL:

001207 22:07:56  bdb:  log_flush: LSN past current end-of-log

No ejecute ALTER TABLE en una tabla BDB en la que usted esté ejecutando transacciones de varias sentencias hasta que todas esas transacciones hayan sido completadas. (La transacción podría ser ignorada.)

ANALYZE TABLE, OPTIMIZE TABLE, y REPAIR TABLE podría causar problemas en tablas para las que usted esté utilizando INSERT DELAYED.

Realizar LOCK TABLE ... y FLUSH TABLES ... no garantiza que no haya una transacción a medio ejecutar en progreso en la tabla.

Las tablas BDB son relativamente lentas de abrir. Si usted tiene muchas tablas BDB en una base de datos, un cliente mysql podría tardar mucho en estar listo si no está utilizando la opción -A o sí está utilizando rehash. Esto es especialmente notable cuando tiene una cache de tablas grande.

La replicación utiliza registro a nivel de consulta: El maestro escribe las sentencias ejecutadas al registro binario. Este es un método de registro muy rápido, compacto, y eficiente que trabaja de manera perfecta en la mayor parte de los casos.

Es posible que los datos en el maestro y el esclavo difieran si una consulta se diseña de manera que la modificación de los datos sea no-determinista (generalmente no es una práctica recomendada, incluso sin hablar de replicación).

Por ejemplo:

Si y únicamente si las sentencias precedentes no tienen una clausula ORDER BY garantizado un orden determinista.

Por ejemplo, en INSERT ... SELECT sin un ORDER BY, el SELECT podría retornar registros en orden diferente (lo que resulta en una fila que termina teniendo diferente rango, es decir, obteniendo un número diferente en la columna AUTO_INCREMENT), dependiendo de las elecciones hechas por los optimizadores en el maestro y el esclavo.

Una consulta está optimizada de manera diferente en el maestro y el esclavo sólo sí:

Este problema podría también afectar a la restauración de bases de datos utilizando mysqlbinlog|mysql.

La manera más fácil de evitar este problema es añadir una clausula ORDER BY a las mencionadas consultas no-deterministas para asegurarse de que los registros son siempre almacenados o modificados en el mismo orden.

En versiones futuras de MySQL, añadiremos automáticamente una clausula ORDER BY allá donde sea necesaria.

Los nombres de archivo de los registros se basan en el nombre del servidor (si no especifica un nombre en la opción de inicio). Tiene que utilizar opciones como --log-bin=old_host_name-bin si usted cambia el nombre de su servidor. Otra opción es renombrar los antiguos archivos para reflejar el cambio al nuevo nombre (si estos son registros binarios, debería editar el archivo de índice del registro binario y arreglar los nombres también). Consulte Sección 5.3.1, “Opciones del comando mysqld”.

mysqlbinlog no borra los archivos temporales tras un comando LOAD DATA INFILE. Consulte Sección 8.5, “La utilidad mysqlbinlog para registros binarios”.

RENAME no funciona con tablas TEMPORARY o tablas utilizadas en una tabla MERGE.

Debido a la manera en que los archivos de definición de talba son almacenados, usted no puede utilizar el carácter 255 (CHAR(255)) en los nombres de tabla, columna, o enumeraciones. Esto será arreglado previsiblemente en la versión 5.1, cuando implementemos un nuevo formato de archivo de definición de tablas.

Cuando utiliza SET CHARACTER SET, usted no puede utilizar caracteres traducidos en los nombres de base de datos, tabla y columna.

No puede utilizar '_' o '%' con ESCAPE en LIKE ... ESCAPE.

Si usted tiene una columna DECIMAL en la que el mismo número se almacena en diferentes formatos (por ejemplo, +01.00, 1.00, 01.00), GROUP BY puede tratar cada valor como uno diferente.

No puede instalar el servidor en otro directorio cuando utiliza MIT-pthreads. Debido a que este problema requiere cambios en los hilos MIT-pthreads, no es probable que lo arreglemos. Consulte Sección 2.8.5, “Notas sobre MIT-pthreads”.

Los valores BLOB y TEXT no puede ser utilizados “de manera fiablemente” en GROUP BY, ORDER BY o DISTINCT. Solo los primeros max_sort_length se utilizan para comparar valores BLOB en estos casos. El valor por defecto de max_sort_length es 1024 y puede cambiarse en el momento de iniciar el servidor. A partir de MySQL 4.0.3, también puede cambiarse en tiempo de ejecución. En versiones más antiguas, una solución alternativa es utilizar una subcadena de caracteres. Por ejemplo:

SELECT DISTINCT LEFT(blob_col,2048) FROM nombre_de_tabla;

Los cálculos numéricos son hechos con BIGINT o DOUBLE (ambos son normalmente de 64 bits de longitud). La precisión que usted obtenga depende de la función. La regla general es que las funciones de bit son realizadas con precisión de BIGINT, IF y ELT() con precisión BIGINT o DOUBLE, y el resto con precisión DOUBLE. Debería evitar utilizar valores sin signo largos si son más grandes de 63 bits (9223372036854775807) para cualquier cosa que no sean campos de tipo bit. La versión 4.0 de MySQL tiene mejor gestión de BIGINT que 3.23.

Puede tener hasta 255 columnas ENUM y SET en una tabla.

En las funciones MIN(), MAX(), y otras funciones de agregación, MySQL actualmente compara las columnas ENUM y SET por su valor de cadena decaracteres en vez de la posición relativa de la cadena en el conjunto.

mysqld_safe redirige todos los mensajes desde mysqld al registro mysqld. Un problema con esto es que si usted ejecuta mysqladmin refresh para cerrar y reabrir el registro, stdout y stderr son redirigidos todavía al registro antiguo. Si usted utiliza --log a menudo, debería editar mysqld_safe para que almacene sus registros en host_name.err en vez de host_name.log de manera que pueda fácilmente recuperar el espacio borrando el registro antiguo y ejecutando mysqladmin refresh.

En una sentencia UPDATE, las columnas son actualizadas de izquierda a drecha. Si se refiere a una columna actualizada, usted obtiene el valor actualizado en vez del original. Por ejemplo, la siguiente sentencia incrementa KEY en 2, no 1:

mysql> UPDATE nombre_de_tabla SET KEY=KEY+1,KEY=KEY+1;

Puede referirse a múltiples tablas temporales en la misma sentencia, pero no puede referirse a ninguna de ellas más de una vez. Por ejemplo, lo siguiente no funciona:

mysql> SELECT * FROM temp_table, temp_table AS t2;
ERROR 1137: Can't reopen table: 'temp_table'

El optimizador podría gestionar DISTINCT de manera diferente cuando esté utilizando columnas ocultas en una join, y cuando no lo haga. En una join, las columnas ocultas se contan como parte del resultado (aunque no sean mostradas), mientras que en las consultas normales, las columnas ocultas no participan en la comparación DISTINCT. Probalemente cambiemos esto en el futuro para que nunca se comparen las columnas ocultas al ejecutar DISTINCT.

Un ejemplo de esto es:

SELECT DISTINCT mp3id FROM band_downloads
       WHERE userid = 9 ORDER BY id DESC;

and

SELECT DISTINCT band_downloads.mp3id
       FROM band_downloads,band_mp3
       WHERE band_downloads.userid = 9
       AND band_mp3.id = band_downloads.mp3id
       ORDER BY band_downloads.id DESC;

En el segundo caso, al utilizar el servidor MySQL 3.23.x, podría obtener dos registros idénticos en el conjunto de resultados (porque los valores en las columnas id ocultas podrían diferir).

Tenga en cuenta que esto pasa solo en las consultas que no tienen columnas pertenecientes al ORDER BY en el resultado.

Si ejecuta un PROCEDURE en una consulta que retorna un conjunto vacío, en algunos casos el PROCEDURE no transforma las columnas.

La creación de una tabla de tipo MERGE no comprueba si los tablas subyacentes son de tipos compatibles.

Si utiliza ALTER TABLE para añadir un índice UNIQUE a una tabla utilizada en una tabla MERGE y después añade un índice normal en la tabla MERGE, el orden de las claves es diferente para las tablas si había una clave no-UNIQUE antigua en la tabla. Esto es porque ALTER TABLE pone índices UNIQUE antes de los índices normales para poder detectar claves duplicadas tan pronto como sea posible.