Verificar la lista de cambios que se encuentra más adelante en esta sección, para ver si cualquiera de ellos podría afectar las aplicaciones en uso. En especial, aquellos marcados como Cambio incompatible; estos resultan en incompatibilidades con versiones anteriores de MySQL, y podrían requerir atención antes de actualizar.

Se debe leer el historial de cambios de MySQL 5.0 para ver qué características significativas nuevas se pueden utilizar. Consulte Sección C.1, “Cambios en la entrega 5.0.x (Desarrollo)”.

Si se está ejecutando el Servidor MySQL para Windows, consulte Sección 2.3.15, “Aumentar la versión de MySQL en Windows”. Hay que tener en cuenta también que dos de los servidores MySQL para Windows cambiaron su nombre. Consulte Sección 2.3.9, “Seleccionar un tipo de servidor MySQL”.

MySQL 5.0 incorporó soporte para procedimientos almacenados. Esto requiere que la tabla proc se encuentre en la base de datos mysql. Para crear este fichero, se debe ejecutar el script mysql_fix_privilege_tables tal como se describe en Sección 2.10.2, “Aumentar la versión de las tablas de privilegios”.

MySQL 5.0 también incorporó soporte para vistas. Esto requiere columnas adicionales de privilegios en las tablas user y db en la base de datos mysql. Para crear estas columnas, se debe ejecutar el script mysql_fix_privilege_tables como se describe en Sección 2.10.2, “Aumentar la versión de las tablas de privilegios”.

Si se está usando replicación, consulte Sección 6.6, “Aumentar la versión de la replicación” para información sobre cómo actualizar la configuración de replicación.

Cambio incompatible: Cambió el orden de indexación para los espacios sobrantes en columnas TEXT en tablas InnoDB y MyISAM. A partir de MySQL 5.0.3, los índices son comparados incluyendo los espacios hasta el final (exactamente como MySQL ordena los campos CHAR, VARCHAR y TEXT). Si se tiene un índice sobre una columna TEXT, se debería ejecutar CHECK TABLE sobre ella. Si la verificación informa de errores, habrá que reconstruir los índices: volcar (dump) y volver a generar la tabla si es InnoDB, o bien ejecutar OPTIMIZE TABLE o REPAIR TABLE si es una tabla MyISAM.

Cambio incompatible: Las tablas MyISAM e InnoDB que tengan columnas DECIMAL y se crearon con MySQL 5.0.3 a 5.0.5 aparecerán corruptas tras una actualización a MySQL 5.0.6. Debe hacerse un volcado de dichas tablas con mysqldump antes de actualizar, y volver a generarlas luego de la actualización. (La misma incompatibilidad ocurriría con estas tablas si fueran creadas en MySQL 5.0.6 y se hiciera un regreso a las versiones de MySQL entre 5.0.3 y 5.0.5).

Cambio incompatible: a partir de MySQL 5.0.3, el servidor ya no carga por defecto las funciones definidas por el usuario, a menos que tengan por lo menos un símbolo auxiliar (por ejemplo, un símbolo xxx_init o xxx_deinit) además del símbolo principal de la función. Este comportamiento puede omitirse con la opción --allow-suspicious-udfs. Consulte Sección 27.2.3.6, “Precauciones de seguridad en funciones definidas por usuarios”.

Incompatible change: El registro (log) de actualización fue eliminado en MySQL 5.0. Si anteriormente se lo tenía habilitado, se debería habilitar el registro binario (binary log) en su lugar.

Cambio incompatible: Fue quitado el soporte para el motor de almacenamiento ISAM. Si se tenían tablas ISAM, se deberán convertir antes de actualizar. Por ejemplo, para convertir una tabla ISAM a fin de utilizar el motor de almacenamiento MyISAM, se emplea esta sentencia:

ALTER TABLE tbl_name ENGINE = MyISAM;

Debe emplearse una sentencia similar para cada tabla ISAM existente en las bases de datos.

Cambio incompatible: Se ha quitado de MySQL 5.0 el soporte para opciones RAID en tablas MyISAM. Si se tienen tablas que utilicen estas opciones, se deberían convertir antes de actualizar. Una forma de hacerlo es realizar un volcado de la tabla con mysqldump, editar el fichero creado para eliminar todas las opciones RAID en las sentencias CREATE TABLE, y luego volver a generar las tablas a partir del fichero. Otra posibilidad es utilizar CREATE TABLE new_tbl ... SELECT raid_tbl para crear una nueva tabla a partir de la tabla RAID. Sin embargo, la parte CREATE TABLE de la sentencia debe contener suficiente información para regenerar los atributos de columna así como los índices, o los atributos de columna podrían perderse y los índices no aparecer en la nueva tabla. Consulte Sección 13.1.5, “Sintaxis de CREATE TABLE”.

Los ficheros .MYD para tablas RAID en una determinada base de datos, son almacenados bajo el directorio de la base de datos, en subdirectorios que tienen nombres consistentes en dos dígitos hexadecimales en el rango de 00 a ff. Luego de convertir todas las tablas que emplean opciones RAID, estos subdirectorios seguirán existiendo pero pueden eliminarse. Hay que cerciorarse de que están vacíos, y borrarlos manualmente. (Si no están vacíos, es señal de que alguna tabla RAID ha quedado sin convertir).

En MySQL 5.0.6, fue modificado el registro binario de procedimientos almacenados y triggers. Este cambio incide sobre la seguridad, la replicación, y la recuperación de datos, como se trata en Sección 19.3, “Registro binario de procedimientos almacenados y disparadores”.

Las columnas DECIMAL ahora se almacenan en un formato más eficiente. Para convertir una tabla a fin de utilizar el nuevo tipo DECIMAL, se le debería aplicar una sentencia ALTER TABLE. Esta sentencia también cambiará las columnas VARCHAR de la tabla para que utilicen el nuevo tipo de columna VARCHAR. Para información acerca de posibles incompatibilidades con aplicaciones preexistentes, consulte Capítulo 23, Matemáticas de precisión.

MySQL 5.0.3 y posteriores emplean matemática de precisión cuando realizan cálculos con valores DECIMAL (64 dígitos decimales) y para redondear números de valor exacto. Consulte Capítulo 23, Matemáticas de precisión.

A partir de MySQL 5.0.3, los espacios sobrantes no se quitan de los valores almacenados en columnas VARCHAR y VARBINARY. Las longitudes máximas para columnas VARCHAR y VARBINARY en MySQL 5.0.3 son de 65.535 caracteres y 65.535 bytes, respectivamente.

Nota: Si se crea una tabla con los nuevos tipos de columnas VARCHAR o VARBINARY en MySQL 5.0.3 o posterior, la tabla será inutilizable si se regresa a una versión anterior a la 5.0.3. Debe hacerse un volcado de la tabla antes de instalar la versión anterior y volver a generarla luego.

A partir de MySQL 5.0.3, BIT es un tipo de dato separado, no un sinónimo para TINYINT(1). Consulte Sección 11.1.1, “Panorámica de tipos numéricos”.

MySQL 5.0.2 incorpora varios modos SQL que permiten un control más estricto sobre el rechazo de registros que tengan valores inválidos o perdidos. Consulte Sección 5.3.2, “El modo SQL del servidor” y Sección 1.7.6.2, “Restricciones (constraints) sobre datos inválidos”. Si se desea habilitar este control pero continuar usando la capacidad de MySQL para almacenar fechas incorrectas, como '2004-02-31', se debería iniciar el servidor con la opción --sql_mode=TRADITIONAL,ALLOW_INVALID_DATES.

A partir de MySQL 5.0.2, las palabras clave SCHEMA y SCHEMAS son aceptadas como sinónimos de DATABASE y DATABASES respectivamente. (Mientras que “schemata” es gramaticalmente correcta e incluso aparece en algunos nombres de tablas y bases de datos de sistema de MySQL 5.0, no puede ser utilizada como palabra clave en la entrada de sentencias).

Las variables de usuario no son case sensitive en MySQL 5.0. En MySQL 4.1, SET @x = 0; SET @X = 1; SELECT @x; creaba dos variables y retornaba 0. En MySQL 5.0, crea una sola variable y devuelve 1.

El flag reconnect en la estructura MYSQL es establecido en 0 por mysql_real_connect(). Solamente experimentan un cambio aquellos programas cliente que no establecen explícitamente este flag a 0 o 1 luego de mysql_real_connect(). Tener habilitada la reconexión automática por defecto se considera muy riesgoso (debido a que los bloqueos de tablas, las tablas temporales, las variables de usuario y las variables de sesión se pierden luego de la reconexión).