MySQL 5.5.29 (64-bit)

Qué hay de nuevo en esta versión:

Funcionalidad Añadido o Cambiado:
- El SHOW de los AUTORES y de MOSTRAR los CONTRIBUYENTES declaraciones están ahora en desuso en MySQL 5.5 y se han eliminado en MySQL 5.6. 

Errores corregidos:
Rendimiento: InnoDB: Los valores de temporización, de bajo nivel de InnoDB las operaciones de lectura fueron ajustados para un mejor rendimiento con rápido como dispositivos de almacenamiento SSD. Esta mejora afecta principalmente a las operaciones de lectura para las columnas BLOB de tablas comprimidas. 
- Cambio Importante: InnoDB: UNA instrucción DML utilizando el índice de combinar el método de acceso podría bloquear el número de filas de la tabla, incluso cuando esas filas no eran parte del conjunto de resultados finales. Esta revisión se reduce el excesivo bloqueo por la liberación de los bloqueos de las filas no coincidentes. Esta optimización afecta sólo a las transacciones con nivel de aislamiento igual o menos estrictas que las de LECTURA COMPROMETIDA; no se aplica a las transacciones con LECTURA REPETIBLE o el nivel de aislamiento SERIALIZABLE. 
- InnoDB: Una línea de DDL operación de una tabla InnoDB informó incorrectamente un valor vacío (") en lugar de la clave correcta valor cuando se informó de un error de clave duplicada para un índice único con un índice de prefijo. 
- InnoDB: Si la instrucción CREATE TABLE falló debido a un error de disco lleno, algo de memoria asignado durante la operación no se ha liberado correctamente. 
- InnoDB: Con el innodb_file_per_table configuración habilitada, una CAÍDA de funcionamiento de la MESA podría causar un accidente, debido a una condición de carrera que dependía del tiempo de espera de solicitudes de I/O. 
- InnoDB: Si el servidor se estrelló en el punto concreto en el que un cambio de búfer de entrada estaba siendo fusionado en un búfer de página de grupo, el registro de transacciones y el cambio de buffer se queda en un estado incoherente. Después de un reinicio, MySQL puede bloquearse después de la lectura de la secundaria correspondiente página de índice. El problema era más probable que ocurra en MySQL 5.5 o posterior, donde el original insertar el almacenamiento en búfer mecanismo generalizado para cubrir otras operaciones. 
- InnoDB: la Inserción de los datos de diferentes longitudes de registro en una tabla InnoDB que utiliza la compresión podría provocar que el servidor a fin con un error. 
- InnoDB: Si una tabla se define con un índice de la longitud de la clave, muy cerca de la parte superior del límite de longitud de 3072, una consulta contra la que el cuadro podría causar un grave error. 
- InnoDB: Cuando un incremento automático de la columna se utiliza un FLOAT o DOUBLE tipo de datos, si el valor de incremento automático se hizo muy grande (mayor que el máximo unsigned long long valor), inserta posteriores podrían fallar o hacer que el servidor se detenga. 
- InnoDB: Si se inicia una transacción con una constante de instantánea, a continuación, los índices nuevos se han añadido a la tabla mientras que la transacción estaba en progreso, una ACTUALIZACIÓN posterior declaración podría incorrectamente encuentro el error:
- HA_ERR_TABLE_DEF_CHANGED: la insuficiencia de la historia de índice
- Este problema podría provocar un error de aserción en las versiones de depuración. 
- InnoDB: El mensaje de error se ha mejorado para el caso de que un error de ACTUALIZACIÓN porque la fila incluye varios valores BLOB mayor de 768 bytes cada uno, haciendo que el tamaño de una fila a exceder de la mitad del tamaño de la página. El mensaje de edad, era engañosa; se sugiere el uso de BLOBs, cuando el 768 bytes prefijo para cada columna BLOB era la causa de que el límite de error:
- Código de Error 1118: el tamaño de la Fila es demasiado grande. El tamaño máximo de la fila para el tipo de tabla, sin contar los BLOBs, es 8126. Tienes que cambiar algunas de las columnas de TEXTO o de Blob
- Una solución para el problema fue crear la tabla con el ROW_FORMAT=DINÁMICOS o ROW_FORMAT=COMPRIMIDO cláusula, que ahora se sugiere en el mensaje. 
- InnoDB: En raras circunstancias, MySQL, se podría aplicar el InnoDB deshacer los expedientes de la orden durante una REVERSIÓN de una operación que modifica una columna BLOB. Este problema podría provocar un error de aserción en las versiones de depuración:
- !bpágina->file_page_was_freed 
- Replicación: las Actualizaciones de escritura del usuario, las variables cuyos valores nunca hubo un esclavo, mientras que el uso de --replicate-ignore-table podría provocar que el esclavo a fallar. 
- Replicación: el acento grave (`) los personajes no siempre fueron manejados correctamente en la generación interna de las sentencias SQL, que a veces puede conducir a errores en el esclavo.
- Replicación: después de una inserción en una tabla no transaccional que fracasó debido a la falta de espacio de disco, el servidor no limpiar correctamente todos los eventos pendientes, que conduce a una aserción o, posiblemente, a otros errores. 
- Muy larga base de datos de nombres en las consultas podría provocar que el servidor de salida. 
- Dentro de un procedimiento almacenado, la ejecución de más de una tabla DELETE que se utiliza mucho alias de tabla podría provocar que el servidor de salida. 
- Muy largo alias de tabla en las consultas podría provocar que el servidor de salida. 
- Intentar crear un incremento automático de columna en una tabla InnoDB con un NULL atributo de tipo podría causar un grave error. 
- UNA instrucción DELETE para una tabla InnoDB podría escribir de transacción incorrecta de metadatos en un registro, causando el servidor a fin con un error. Para evitar este problema, reduzca la longitud especificada de la clave primaria a menos de 1K bytes. 
- ejecución Repetida de una consulta que contiene una subconsulta que usa MAX() podría resultar en un aumento de consumo de memoria. 
- USO dbname podría fallar con el Desconocido de la base de datos cuando dbname contenía múltiples acento grave (`) caracteres. 
- La configure.pl script que convierte GNU configurar opciones para CMake equivalentes genera una salida errónea de la --con-cliente-ldflags y --mysqld-ldflags opciones. Ahora ignora esas opciones. 
- VER PERFIL podría ser utilizado para causar el exceso de consumo de memoria del servidor. 
- El hilo de la caché de la aplicación trabajado en LIFO en lugar de FIFO de moda y podría resultar en un hilo que se negación de servicio (aunque esto era una posibilidad remota). 
- Dentro de un programa almacenado, la memoria asignada para mantener la condición de información no fue liberado hasta la salida del programa, conduce a un exceso de uso de la memoria. 
- Inadecuado de limpieza de memoria podría provocar que el servidor de salida. 
- Otorgar o revocar el PROXY privilegio provocó que el servidor de salida si se inició el servidor con la opción --skip-name-resolve. 
- CREAR USUARIO y SOLTAR USUARIO podría fallar a ras de los privilegios, que requieren FLUSH PRIVILEGES para ser utilizado de forma explícita. 
- Acceso a INFORMATION_SCHEMA tablas a través de un juicio, pérdida de la memoria. 
- Una pérdida de memoria puede ocurrir por las consultas que contiene una subconsulta que utiliza GRUPO en el exterior de la columna. 
- En Microsoft Windows con CMake 2.6, el proceso de compilación no se detendría si el create_initial_db paso fallado.
- La prueba en mysqld_safe por la presencia de la --plugin_dir opción y la asignación de un valor predeterminado a que se realizaron antes de que el argumento real de análisis se llevó a cabo. 
- revisa la TABLA y REPARACIÓN de la MESA de accidente en caso de una tabla MyISAM había un corrupto clave (.MYI) archivo. Ahora el servidor produce un error. 
- Inadecuado de limpieza de memoria podría provocar que el servidor de salida. 
- Una pérdida de memoria debido a la falta de limpieza después de QUICK_INDEX_MERGE_SELECT/Único. 
- El número de errores de conexión de un host determinado como contado por el servidor periódicamente el reset, con el resultado de que max_connect_errors nunca fue alcanzado y hosts no válidos nunca fueron bloqueados desde intentando conectarse. 
- Durante la optimización, ZEROFILL valores se pueden convertir en las constantes de cadena. Sin embargo, el CASO de expresiones no tratar de cambiar los tipos de datos después de la etapa de planificación, que conduce a la conclusión del CASO de un puntero nulo en lugar de su argumento. 
- En las versiones de depuración, una InnoDB afirmación era demasiado agresivo sobre la prohibición de un campo abierto. 
- En Windows, el Perl versión de mysql_install_db sistema creado las tablas en la base de datos mysql que se no se rellena correctamente. 
- mysqld_safe ignorado el valor de UMASK variable de entorno, que conduce a un comportamiento diferente de mysqld con respecto al modo de acceso de los archivos creados. Ahora mysqld_safe (y mysqld_multi) intento de aproximar el comportamiento de la misma como mysqld. 
- LAST_INSERT_ID(expr) no trabajo para expr valores mayores que el mayor firmado valor BIGINT.