Capítulo 1. Información general
Anterior |  | Siguiente

## Capítulo 1. Información general

El software MySQL® proporciona un servidor de base de datos SQL (Structured Query Language) muy rápido, multi-threaded, multi usuario y robusto. El servidor MySQL está diseñado para entornos de producción críticos, con alta carga de trabajo así como para integrarse en software para ser distribuido. MySQL es una marca registrada de MySQL AB.

El software MySQL tiene una doble licencia. Los usuarios pueden elegir entre usar el software MySQL como un producto Open Source bajo los términos de la licencia GNU General Public License (http://www.fsf.org/licenses/) o pueden adquirir una licencia comercial estándard de MySQL AB. Consulte http://www.mysql.com/company/legal/licensing/ para más información acerca de nuestras políticas de licencia.

La siguiente lista describe algunas secciones de particular interés en este manual:

- Para una discusión acerca de las capacidades del servidor de base de datos MySQL consulte Sección 1.4.2, “Las principales características de MySQL”.

- Para instrucciones acerca de la instalación, consulte Capítulo 2, Instalar MySQL.

- Para consejos sobre portar el software MySQL a nuevas arquitecturas o sistemas operativos, consulte Apéndice D, Portar a otros sistemas.

- Para información acerca de actualizar desde la versión 4.1, consulte Sección 2.10.1, “Aumentar la versión de 4.1 a 5.0”.

- Para un tutorial introductorio al servidor de base de datos MySQL, consulte Capítulo 3, Curso (tutorial) de MySQL.

- Para ejemplos de SQL e información de rendimiento, consulte el directorio de pruebas de rendimiento (`sql-bench` en la distribución).

- Para la historia de nuevas características y fallos arreglados, consulte Apéndice C, Historial de cambios de MySQL.

- Para una lista de fallos conocidos y características no implementadas, consulte Sección A.8, “Problemas conocidos en MySQL”.

- Para la lista de todos los que han contribuido a este proyecto, consulte Apéndice B, Credits.

Importante:

Informes de errores (a menudo llamados "bugs"), así como preguntas y comentarios, deben enviarse a http://bugs.mysql.com. Consulte Sección 1.6.1.3, “Cómo informar de bugs y problemas”.

Si encuentra un fallo de seguridad importante en el servidor MySQL, por favor comuníquelo inmediatamente mediante un correo electrónico a `<security@mysql.com>`.

## 1.1. Sobre este manual

Este es el manual de referencia para el servidor de base de datos MySQL, versión 5.0, hasta la versión 5.0.9-beta. No está destinado para usarse con versiones más antiguas del software MySQL debido a las numerosas diferencias funcionales y de otro tipo entre MySQL 5.0 y versiones previas. Si usa una versión anterior del software MySQL, por favor consulte Manual de referencia de MySQL 4.1, que cubre las series 3.22, 3.23, 4.0, y 4.1 del software MySQL. Las diferencias entre versiones menores de MySQL 5.0 están destacadas en este texto con referencias a los números de versiones (5.0.`x`).

Este manual es una referencia, por lo que no proporciona instrucciones sobre conceptos generales de SQL o de bases de datos relacionales. Tampoco enseña sobre cómo usar su sistema operativo o su intérprete de línea de comandos.

El software de base de datos MySQL está bajo desarrollo constante, y el Manual de Referencia se actualiza constantemente. La versión más reciente de este manual está disponible en línea permitiendo búsquedas en http://dev.mysql.com/doc/. Hay otros formatos disponibles, incluyendo HTML, PDF, y Windows CHM.

El formato básico para toda la documentación MySQL consiste en un conjunto de ficheros DocBook XML. HTML y otros formatos se producen automáticamente a partir de los mismos, usando entre otras herramientas DocBook XSL stylesheets.

Si tiene sugerencias acerca de correcciones o contenido de este manual, por favor envíelos al equipo de documentación en `<docs@mysql.com>`.

Este manual lo escribió inicialmente David Axmark y Michael "Monty" Widenius. Lo mantiene el equipo de documentación de MySQL formado por Paul DuBois, Stefan Hinz, Mike Hillyer, y Jon Stephens. Para consultar todos los colaboradores, consulte Apéndice B, Credits.

El copyright de este manual es propiedad de la compañía sueca MySQL AB. MySQL® y el logo MySQL logo son marcas registradas de MySQL AB. Otras marcas y marcas registradas a las que se hace referencia en este manual son propiedad de sus respectivos propietarios, y se usan sólo con intenciones de identificación.

## 1.2. Convenciones utilizadas en este manual

Este manual usa ciertas convenciones tipográficas:

- `El texto de este estilo` se usa para sentencias SQL; nombres de bases de datos, tablas y columnnas; código C y Perl; y variables de entorno. Ejemplo: "Para recargar las tablas de permisos use el comando `FLUSH PRIVILEGES`".

- `El texto de este estilo` se usa para entrada de variables las cuales debe substituir por un valor de su propia elección.

- Nombres de ficheros y directorios se escriben así: "El fichero global `my.cnf` se encuentra en el directorio `/etc`".

- Las secuencias de carácteres se escriben así: "Para especificar un comodín, use el carácter '`%`'."

- El texto de este estilo se usa para enfatizar.

- El texto de este estilo se usa en las cabeceras y para dar un enfásis especialmente fuerte.

Cuando se muestran comandos que deben ser ejecutados en un programa particular, el programa se indica con un prompt mostrado antes del comando. Por ejemplo, `shell>` indica un comando que se ejecuta desde el login shell, y `mysql>` indica un comando que se ejecuta desde el programa cliente mysql :

    shell> escriba un comando de shell aquí
    mysql> escriba un comando mysql aquí

El "shell" es su intérprete de comandos. En Unix, esto es normalmente un programa como sh csh. En Windows, el programa equivalente es command.com o cmd.exe, normalmente ejecutado en una ventana de consola.

Cuando introduzca un comando u órden no escriba el prompt mostrado en el ejemplo.

Nombres de bases de datos, tablas y columnas a menudo deben reemplazarse en los comandos. Para indicar que dicha substitución es necesaria, el manual usa `db_name`, `tbl_name`, y `col_name`. Por ejemplo, puede ver un comando como este:

    mysql> SELECT col_name FROM db_name.tbl_name;

Significa que si quisiera introducir un comando similar, debería escribir su propio nombre de base de datos, tabla y columna, tal vez así:

    mysql> SELECT author_name FROM biblio_db.author_list;

Las palabras clave SQL no son case sensitive y pueden escribirse en mayúsculas o minúsculas. Este manual usa mayúsculas.

En descripciones de sintaxis, corchetes ('`[`' y '`]`') se usan para indicar palabras o cláusulas opcionales. Por ejemplo, en el siguiente comando, `IF EXISTS` es opcional:

    DROP TABLE [IF EXISTS] tbl_name

Cuando un elemento de sintaxis consiste en un número de alternativas, las alternativas se separan mediante barras verticales ('`|`'). Cuando un miembro de una serie de elecciones puede ser elegido, las alternativas se muestran entre corchetes ('`[`' y '`]`'):

    TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)

Cuando un miembro de una serie de elecciones debe ser elegido, las alternativas se muestran entre llaves ('`{`' y '`}`'):

    {DESCRIBE | DESC} tbl_name [col_name | wild]

Puntos suspensivos (`...`) indica la omisión de una parte del comando, típicamente para proporcionar una versión corta de una sintaxis más compleja. Por ejemplo, `INSERT ... SELECT` es la versión corta de un comando `INSERT` seguido de un comando `SELECT`.

Puntos suspensivos pueden tambier indicar que el elemento de sintaxis precedente de un comando puede repertirse. En el siguiente ejemplo, pueden darse varios valores `reset_option` cada uno de ellos tras el primero precedidos por comas:

    RESET reset_option [,reset_option] ...

Los comandos para inicializar variables del shell se muestran usando la sintaxis del shell Bourne. Por ejemplo, la secuencia para incializar una variable de entorno y ejecutar un comando es la siguiente con la sintaxis del shell Bourne:

    shell> VARNAME=value some_command

Si utiliza csh o tcsh, debe proporcionar comandos ligeramente distintos. Debería ejecutar la secuencia anterior así:

    shell> setenv VARNAME value
    shell> some_command

## 1.3. Panorámica de MySQL AB

MySQL AB de los fundadores de MySQL y principales desarrolladores. MySQL AB se estableció originalmente en Suecía por David Axmark, Allan Larsson, y Michael "Monty" Widenius.

Nos dedicamos a desarrollar el software para la base de datos MySQL y promocionarlo a nuevos usuarios. MySQL AB posee el copyright del código fuente MySQL, el logo MySQL y la marca registrada, y su manual. Consulte Sección 1.4, “Panorámica del sistema de gestión de base de datos MySQL”.

Los valores clave MySQL muestran nuestra dedicación a MySQL y Open Source.

Los valores clave dirigen cómo MySQL AB trabaja el software de base de datos MySQL:

- Ser la mejor y más usada base de datos en el mundo.

- Estar disponible y ser comprable por cualquiera.

- Fácil de usar.

- Mejorarlo contínuamente mientras es rápido y seguro.

- Ser divertido de usar y mejorar.

- Libre de errores.

Estos son los valores clave de la compañía MySQL AB y sus empleados:

- Suscribimos la filosofía Open Source y apoyamos la comunidad Open Source.

- Ser buenos ciudadanos.

- Preferimos socios que compartan nuestros valores y forma de pensar.

- Responder los correos electrónicos y proporcionar soporte.

- Somos una compañía virtual, conectada con otras.

- Estamos en contra de las patentes de software.

El sitio web MySQL (http://www.mysql.com/) proporciona la última información sobre MySQL y MySQL AB

La parte "AB" del nombre de la compañía es el acrónimo del sueco "aktiebolag", o "stock company", o "sociedad anónima". Se traduce como "MySQL, Inc" o "MySQL, SA". De hecho, MySQL, Inc. y MySQL GmbH son ejemplos de empresas subsidiarias de MySQL AB. Están establecidas en los Estados Unidos y Alemania respectivamente.

## 1.4. Panorámica del sistema de gestión de base de datos MySQL

MySQL, el sistema de gestión de bases de datos SQL Open Source más popular, lo desarrolla, distribuye y soporta MySQL AB. MySQL AB es una compañía comercial, fundada por los desarrolladores de MySQL. Es una compañía Open Source de segunda generación que une los valores y metodología Open Source con un exitoso modelo de negocio.

El sitio web MySQL (http://www.mysql.com/) proporciona la última información sobre MySQL y MySQL AB.

- MySQL es un sistema de gestión de bases de datos

  Una base de datos es una colección estruturada de datos. Puede ser cualquier cosa, desde una simple lista de compra a una galería de pintura o las más vastas cantidades de información en una red corporativa. Para añadir, acceder, y procesar los datos almacenados en una base de datos, necesita un sistema de gestión de base de datos como MySQL Server. Al ser los computadores muy buenos en tratar grandes cantidades de datos, los sistemas de gestión de bases de datos juegan un papel central en computación, como aplicaciones autónomas o como parte de otras aplicaciones.

- MySQL es un sistema de gestión de bases de datos relacionales

  Una base de datos relacional almacena datos en tablas separadas en lugar de poner todos los datos en un gran almacén. Esto añade velocidad y flexibilidad. La parte SQL de "MySQL"se refiere a "Structured Query Language". SQL es el lenguaje estandarizado más común para acceder a bases de datos y está definido por el estándard ANSI/ISO SQL. El estándard SQL ha evolucionado desde 1986 y existen varias versiones. En este manual, "SQL-92" se refiere al estándard del 1992, "SQL:1999" se refiere a la versión del 1999, y "SQL:2003" se reviere a la versión actual del estándard. Usamos la frase "el estándard SQL" para referirnos a la versión actual de SQL.

- MySQL software es Open Source.

  Open Source significa que es posible para cualquiera usar y modificar el software. Cualquiera puede bajar el software MySQL desde internet y usarlo sin pagar nada. Si lo desea, puede estudiar el código fuente y cambiarlo para adapatarlo a sus necesidades. El software MySQL usa la licencia GPL (GNU General Public License), http://www.fsf.org/licenses/, para definir lo que puede y no puede hacer con el software en diferentes situaciones. Si no se encuentra cómodo con la GPL o necesita añadir código MySQL en una aplicación comercial, puede comprarnos una licencia comercial. Consulte la Introducción a las Licencias MySQL para más información (http://www.mysql.com/company/legal/licensing/).

- El servidor de base de datos MySQL es muy rápido, fiable y fácil de usar.

  Si esto es lo que está buscando, debería probarlo. El servidor MySQL también tiene una serie de características prácticas desarrolladas en cooperación con los usuarios. Puede encontrar comparaciones de rendimiento de MySLQL Server con otros sistemas de gestión de bases de datos en nuestra página de comparativas de rendimiento. Consulte Sección 7.1.4, “El paquete de pruebas de rendimiento (benchmarks) de MySQL”.

  MySQL Server se desarrolló originalmente para tratar grandes bases de datos mucho más rápido que soluciones existentes y ha sido usado con éxito en entornos de producción de alto rendimiento durante varios años. MySQL Server ofrece hoy en día una gran cantidad de funciones. Su conectividad, velocidad, y seguridad hacen de MySQL Server altamente apropiado para acceder bases de datos en Internet

- MySQL Server trabaja en entornos cliente/servidor o incrustados

  El software de bases de datos MySQL es un sistema cliente/servidor que consiste en un servidor SQL multi-threaded que trabaja con diferentes bakends, programas y bibliotecas cliente, herramientas administrativas y un amplio abanico de interfaces de programación para aplicaciones (APIs).

  También proporcionamos el MySQL Server como biblioteca incrustada multi-threaded que puede lincar en su aplicación para obtener un producto más pequeño, rápido y fácil de administrar.

- Una gran cantidad de software de contribuciones está disponible para MySQL

  Es muy posible que su aplicación o lenguaje favorito soporte el servidor de base de datos MySQL.

La forma oficial de pronunciar "MySQL" es "My Ess Que Ell" (no "my sicuel"), pero no importa si lo pronuncia como "my sicuel" o de alguna otra forma.

### 1.4.1. Historia de MySQL

Empezamos con la intención de usar `mSQL` para conectar a nuestras tablas utilizando nuestras propias rutinas rápidas de bajo nivel (ISAM). Sin embargo y tras algunas pruebas, llegamos a la conclusión que `mSQL` no era lo suficientemente rápido o flexible para nuestras necesidades. Esto provocó la creación de una nueva interfaz SQL para nuestra base de datos pero casi con la misma interfaz API que `mSQL`. Esta API fue diseñada para permitir código de terceras partes que fue escrito para poder usarse con `mSQL` para ser fácilmente portado para el uso con MySQL.

La derivación del nombre MySQL no está clara. Nuestro directorio base y un gran número de nuestras bibliotecas y herramientas han tenido el prefijo "my" por más de 10 años. Sin embargo, la hija del co-fundador Monty Widenius también se llama My. Cuál de los dos dió su nombre a MySQL todavía es un misterio, incluso para nosotros.

El nombre del delfín de MySQL (nuestro logo) es "Sakila", que fué elegido por los fundadores de MySQL AB de una gran lista de nombres sugerida por los usuarios en el concurso "Name the Dolphin" (ponle nombre al delfín). El nombre ganador fue enviado por Ambrose Twebaze, un desarrollador de software Open Source de Swaziland, África. Según Ambrose, el nombre femenino de Sakila tiene sus raíces en SiSwate, el idioma local de Swaziland. Sakila también es el nombre de una ciudad en Arusha, Tanzania, cerca del país de origen de Ambrose, Uganda.

### 1.4.2. Las principales características de MySQL

La siguiente lista describe algunas de las características más importantes del software de base de datos MySQL. Consulte Sección 1.5, “Mapa de desarrollo de MySQL” para más información acerca de las características actuales y próximas.

- Interioridades y portabilidad

  - Escrito en C y en C++

  - Probado con un amplio rango de compiladores diferentes

  - Funciona en diferentes plataformas. Consulte Sección 2.1.1, “Sistemas operativos que MySQL soporta”.

  - Usa GNU Automake, Autoconf, y Libtool para portabilidad.

  - APIs disponibles para C, C++, Eiffel, Java, Perl, PHP, Python, Ruby, y Tcl. Consulte Capítulo 24, APIs de MySQL.

  - Uso completo de multi-threaded mediante threads del kernel. Pueden usarse fácilmente multiple CPUs si están disponibles.

  - Proporciona sistemas de almacenamiento transaccionales y no transaccionales.

  - Usa tablas en disco B-tree (`MyISAM`) muy rápidas con compresión de índice.

  - Relativamente sencillo de añadir otro sistema de almacenamiento. Esto es útil si desea añadir una interfaz SQL para una base de datos propia.

  - Un sistema de reserva de memoria muy rápido basado en threads.

  - Joins muy rápidos usando un multi-join de un paso optimizado.

  - Tablas hash en memoria, que son usadas como tablas temporales.

  - Las funciones SQL están implementadas usando una librería altamente optimizada y deben ser tan rápidas como sea posible. Normalmente no hay reserva de memoria tras toda la inicialización para consultas.

  - El código MySQL se prueba con Purify (un detector de memoria perdida comercial) así como con Valgrind, una herramienta GPL (http://developer.kde.org/~sewardj/).

  - El servidor está disponible como un programa separado para usar en un entorno de red cliente/servidor. También está disponible como biblioteca y puede ser incrustado (linkado) en aplicaciones autónomas. Dichas aplicaciones pueden usarse por sí mismas o en entornos donde no hay red disponible..

- Tipos de columnas

  - Diversos tipos de columnas: enteros con/sin signo de 1, 2, 3, 4, y 8 bytes de longitud, `FLOAT`, `DOUBLE`, `CHAR`, `VARCHAR`, `TEXT`, `BLOB`, `DATE`, `TIME`, `DATETIME`, `TIMESTAMP`, `YEAR`, `SET`, `ENUM`, y tipos espaciales OpenGIS. Consulte Capítulo 11, Tipos de columna.

  - Registros de longitud fija y longitud variable.

- Sentencias y funciones

  - Soporte completo para operadores y funciones en las cláusulas de consultas `SELECT` y `WHERE`. Por ejemplo:

        mysql> SELECT CONCAT(first_name, ' ', last_name)
            -> FROM citizen
            -> WHERE income/dependents > 10000 AND age > 30;

  - Soporte completo para las cláusulas SQL `GROUP BY` y `ORDER BY`. Soporte de funciones de agrupación (`COUNT()`, `COUNT(DISTINCT ...)`, `AVG()`, `STD()`, `SUM()`, `MAX()`, `MIN()`, y `GROUP_CONCAT()`).

  - Soporte para `LEFT OUTER JOIN` y `RIGHT OUTER JOIN` cumpliendo estándards de sintaxis SQL y ODBC.

  - Soporte para alias en tablas y columnas como lo requiere el estándard SQL.

  - `DELETE`, `INSERT`, `REPLACE`, y `UPDATE` devuelven el número de filas que han cambiado (han sido afectadas). Es posible devolver el número de filas que serían afectadas usando un flag al conectar con el servidor.

  - El comando específico de MySQL `SHOW` puede usarse para obtener información acerca de la base de datos, el motor de base de datos, tablas e índices. El comando `EXPLAIN` puede usarse para determinar cómo el optimizador resuelve una consulta.

  - Los nombres de funciones no colisionan con los nombres de tabla o columna. Por ejemplo, `ABS` es un nombre válido de columna. La única restricción es que para una llamada a una función, no se permiten espacios entre el nombre de función y el '`(`' a continuación. Consulte Sección 9.6, “Tratamiento de palabras reservadas en MySQL”.

  - Puede mezclar tablas de distintas bases de datos en la misma consulta (como en MySQL 3.22).

- Seguridad

  - Un sistema de privilegios y contraseñas que es muy flexible y seguro, y que permite verficación basada en el host. Las contraseñas son seguras porque todo el tráfico de contraseñas está encriptado cuando se conecta con un servidor.

- Escalabilidad y límites

  - Soporte a grandes bases de datos. Usamos MySQL Server con bases de datos que contienen 50 millones de registros. También conocemos usuarios que usan MySQL Server con 60.000 tablas y acerca de 5.000.000 de registros.

  - Se permiten hasta 64 índices por tabla (32 antes de MySQL 4.1.2). Cada índice puede consistir desde 1 hasta 16 columnas o partes de columnas. El máximo ancho de límite son 1000 bytes (500 antes de MySQL 4.1.2).Un índice puede usar prefijos de una columna para los tipos de columna `CHAR`, `VARCHAR`, `BLOB`, o `TEXT`.

- Conectividad

  - Los clientes pueden conectar con el servidor MySQL usando sockets TCP/IP en cualquier plataforma. En sistemas Windows de la familia NT (NT,2000,XP, o 2003), los clientes pueden usar named pipes para la conexión. En sistemas Unix, los clientes pueden conectar usando ficheros socket Unix.

  - En MySQL 5.0, los servidores Windows soportan conexiones con memoria compartida si se inicializan con la opción `--shared-memory`. Los clientes pueden conectar a través de memoria compartida usando la opción `--protocol=memory`.

  - La interfaz para el conector ODBC (MyODBC) proporciona a MySQL soporte para programas clientes que usen conexiones ODBC (Open Database Connectivity). Por ejemplo, puede usar MS Access para conectar al servidor MySQL. Los clientes pueden ejecutarse en Windows o Unix. El código fuente de MyODBC está disponible. Todas las funciones para ODBC 2.5 están soportadas, así como muchas otras. Consulte Sección 25.1, “MySQL Connector/ODBC”.

  - La interfaz para el conector J MySQL proporciona soporte para clientes Java que usen conexiones JDBC. Estos clientes pueden ejecutarse en Windows o Unix. El código fuente para el conector J está disponible. Consulte Sección 25.4, “MySQL Connector/J”.

- Localización

  - El servidor puede proporcionar mensajes de error a los clientes en muchos idomas. Consulte Sección 5.9.2, “Escoger el idioma de los mensajes de error”.

  - Soporte completo para distintos conjuntos de carácteres, incluyendo `latin1` (ISO-8859-1), `german`, `big5`, `ujis`, y más. Por ejemplo, los carácteres escandinavos '`â`', '`ä`' y '`ö`' están permitidos en nombres de tablas y columnas. El soporte para Unicode está disponible

  - Todos los datos se guardan en el conjunto de carácteres elegido. Todas las comparaciones para columnas normales de cadenas de carácteres son case-insensitive.

  - La ordenación se realiza acorde al conjunto de carácteres elegido (usando colación Sueca por defecto). Es posible cambiarla cuando arranca el servidor MySQL. Para ver un ejemplo de ordenación muy avanzada, consulte el código Checo de ordenación. MySQL Server soporta diferentes conjuntos de carácteres que deben ser especificados en tiempo de compilación y de ejecución.

- Clientes y herramientas

  - MySQL server tiene soporte para comandos SQL para chequear, optimizar, y reparar tablas. Estos comandos están disponibles a través de la línea de comandos y el cliente mysqlcheck. MySQL también incluye myisamchk, una utilidad de línea de comandos muy rápida para efectuar estas operaciones en tablas `MyISAM`. Consulte Capítulo 5, Administración de bases de datos.

  - Todos los programas MySQL pueden invocarse con las opciones `--help` o `-?` para obtener asistencia en línea.

### 1.4.3. Estabilidad de MySQL

Esta sección trata las preguntas "¿Qué estabilidad tiene MySQL Server?" y, "¿Puedo fiarme de MySQL Server para este proyecto?" Intentaremos clarificar estas cuestiones y responder algunas preguntas importantes que preocupan a muchos usuarios potenciales. La información en esta sección se basa en datos recopilados de las listas de correo, que son muy activas para identificar problemas así como para reportar tipos de usos.

El código original se remonta a los principos de los años 80. En TcX, la predecesora de MySQL AB, el código MySQL ha funcionado en proyectos desde mediados de 1996 sin ningún problema. Cuando el software de base de datos MySQL fue distribuído entre un público más amplio, nuestros nuevos usuarios rápidamente encontraron trozos de código no probados. Cada nueva versión desde entonces ha tenido pocos problemas de portabilidad incluso considerando que cada nueva versión ha tenido muchas nuevas funcionalidades.

Cada versión de MySQL Server ha sido usable. Los problemas han ocurrido únicamente cuando los usuarios han probado código de las "zonas grises". Naturalmente, los nuevos usuarios no conocen cuáles son estas zonas; esta sección, por lo tanto, trata de documentar dichas áreas conocidas a día de hoy. Las descripciones mayormente se corresponden con la versión 3.23, 4.0 y 4.1 de MySQL Server. Todos los bugs reportados y conocidos se arreglan en la última versión, con las excepciones listadas en las secciones de bugs y que están relacionados con problemas de diseño. Consulte Sección A.8, “Problemas conocidos en MySQL”.

El diseño de MySQL Server es multi capa, con módulos independientes. Algunos de los últimos módulos se listan a continuación con una indicación de lo bien testeados que están:

- Replicatión (Estable)

  Hay grandes grupos de servidores usando replicación en producción, con buenos resultados. Se trabaja para mejorar características de replicación en MySQL 5.x.

- `InnoDB` tablas (Estable)

  El motor de almacenamiento transaccional `InnoDB` es estable y usado en grandes sistemas de producción con alta carga de trabajo.

- `BDB` tablas (Estable)

  El código `Berkeley DB` es muy estable, pero todavía lo estamos mejorando con el interfaz del motor de almacenamiento transaccional `BDB` en MySQL Server.

- Búsquedas Full-text (Estable)

  Búsquedas Full-text es ámpliamente usada.

- `MyODBC` 3.51 (Estable)

  `MyODBC` 3.51 usa ODBC SDK 3.51 y es usado en sistemas de producción ámpliamente. Algunas cuestiones surgidas parecen ser cuestión de las aplicaciones que lo usan e independientes del controlador ODBC o la base de datos subyacente.

### 1.4.4. Dimensiones máximas de las tablas MySQL

En MySQL 5.0, usando el motor de almacenamiento `MyISAM`, el máximo tamaño de las tablas es de 65536 terabytes (256 ^ 7 - 1 bytes). Por lo tanto, el tamaño efectivo máximo para las bases de datos en MySQL usualmente los determinan los límites de tamaño de ficheros del sistema operativo, y no por límites internos de MySQL.

El motor de almacenamiento `InnoDB` mantiene las tablas en un espacio que puede ser creado a partir de varios ficheros. Esto permite que una tabla supere el tamaño máximo individual de un fichero. Este espacio puede incluir particiones de disco, lo que permite tablas extremadamente grandes. El tamaño máximo del espacio de tablas es 64TB.

La siguiente tabla lista algunos ejemplos de límites de tamaño de ficheros de sistemas operativos. Esto es sólo una burda guía y no pretende ser definitiva. Para la información más actual, asegúrese de consultar la documentación específica de su sistema operativo.

Sistema operativo | Tamaño máximo de fichero
Linux 2.2-Intel 32-bit | 2GB (LFS: 4GB)
Linux 2.4 | (usando sistema de ficheros ext3) 4TB
Solaris 9/10 | 16TB
Sistema de ficheros NetWare w/NSS | 8TB
win32 w/ FAT/FAT32 | 2GB/4GB
win32 w/ NTFS | 2TB (posiblemente mayor)
MacOS X w/ HFS+ | 2TB

En Linux 2.2, puede utilizar tablas `MyISAM` mayores de 2GB usando el parche para LFS (Large File Support) en el sistema de ficheros ext2. En Linux 2.4 y posteriores, existen parches para ReiserFS soportando grandes archivos (hasta 2TB). La mayoría de distribuciones Linux se basan en el kernel 2.4 o 2.6 e incluyen todos los parches LFS necesarios. Con JFS y XFS, se permiten ficheros mayores de un petabyte para Linux. Sin embargo, el tamaño máximo de ficheros todavía depende de diversos factores, uno de ellos siendo el sistema de ficheros usado para almacenar tablas MySQL.

Para un resumen más detallado acerca de LFS en Linux, recomendamos la página de Andreas Jaeger Large File Support in Linux en http://www.suse.de/~aj/linux_lfs.html.

Usuarios de Windows, por favor tengan en cuenta que: FAT and VFAT (FAT32) no se consideran apropiados para sistemas de producción con MySQL. Use NTFS para ello.

Por defecto, MySQL crea tablas `MyISAM` con una estructura interna que permite un tamaño máximo de unas 4GB. Puede chequear el tamaño máximo de tabla para una tabla con el comando `SHOW TABLE STATUS` o con myisamchk -dv `tbl_name`. Consulte Sección 13.5.4, “Sintaxis de `SHOW`”.

Si necesita una tabla `MyISAM` con un tamaño mayor a 4GB (y su sistema operativo soporta ficheros grandes), el comando `CREATE TABLE` permite las opciones `AVG_ROW_LENGTH` y `MAX_ROWS`. Consulte Sección 13.1.5, “Sintaxis de `CREATE TABLE`”. También puede cambiar esas opciones con `ALTER TABLE` una vez que la tabla se ha creado, para aumentar el tamaño máximo de la tabla. Consulte Sección 13.1.2, “Sintaxis de `ALTER TABLE`”.

Otros métodos para cambiar los límites de tamaño de ficheros para tablas `MyISAM` son:

- Si una tabla es de sólo lectura, puede usar myisampack para comprimirla. myisampack normalmente comprime una tabla al menos un 50%, lo que permite, a efectos prácticos, tablas mucho mayores. myisampack puede mezclar múltiples tablas en una misma tabla. Consulte Sección 8.2, “myisampack, el generador de tablas comprimidas de sólo lectura de MySQL”.

- MySQL incluye la biblioteca `MERGE` que permite tratar una colección de tablas `MyISAM` con una estructura idéntica en una tabla `MERGE`. Consulte Sección 14.2, “El motor de almacenamiento `MERGE`”.

### 1.4.5. Conformidad con el efecto 2000

MySQL Server por sí mismo no tiene problemas de conformidad con el año 2000 (Y2K):

- MySQL Server utiliza funciones de tiempo Unix que tratan las fechas hasta el año `2037` para valores `TIMESTAMP`. Para valores `DATE` y `DATETIME`, se aceptan fechas hasta el año `9999`.

- Todas las funciones de fecha MySQL se implementan en un mismo fichero fuente, `sql/time.cc`, y están programados cuidadosamente para no tener problemas con el año 2000.

- En MySQL 5.0 y posterior, el tipo de columna `YEAR` puede almacenar los años `0` y `1901` hasta `2155` en un byte y mostrarlo usando de dos a cuatro dígitos. Todos los años de dos dígitos se consideran en el rango `1970` hasta `2069`, lo que significa que si almacena `01` en una columna de tipo `YEAR`, MySQL Server lo trata como `2001`.

La siguiente demostración ilustra que MySQL Server no tiene problemas con valores `DATE` o `DATETIME` hasta el año 9999, ni tampoco tiene problemas con valores de tipo `TIMESTAMP` hasta el año 2030:

    mysql> DROP TABLE IF EXISTS y2k;
    Query OK, 0 rows affected (0.01 sec)

    mysql> CREATE TABLE y2k (date DATE,
        ->                   date_time DATETIME,
        ->                   time_stamp TIMESTAMP);
    Query OK, 0 rows affected (0.01 sec)

    mysql> INSERT INTO y2k VALUES
        -> ('1998-12-31','1998-12-31 23:59:59',19981231235959),
        -> ('1999-01-01','1999-01-01 00:00:00',19990101000000),
        -> ('1999-09-09','1999-09-09 23:59:59',19990909235959),
        -> ('2000-01-01','2000-01-01 00:00:00',20000101000000),
        -> ('2000-02-28','2000-02-28 00:00:00',20000228000000),
        -> ('2000-02-29','2000-02-29 00:00:00',20000229000000),
        -> ('2000-03-01','2000-03-01 00:00:00',20000301000000),
        -> ('2000-12-31','2000-12-31 23:59:59',20001231235959),
        -> ('2001-01-01','2001-01-01 00:00:00',20010101000000),
        -> ('2004-12-31','2004-12-31 23:59:59',20041231235959),
        -> ('2005-01-01','2005-01-01 00:00:00',20050101000000),
        -> ('2030-01-01','2030-01-01 00:00:00',20300101000000),
        -> ('2040-01-01','2040-01-01 00:00:00',20400101000000),
        -> ('9999-12-31','9999-12-31 23:59:59',99991231235959);
    Query OK, 14 rows affected (0.01 sec)
    Records: 14  Duplicates: 0  Warnings: 2

    mysql> SELECT * FROM y2k;
    +------------+---------------------+----------------+
    | date       | date_time           | time_stamp     |
    +------------+---------------------+----------------+
    | 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
    | 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
    | 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
    | 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
    | 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
    | 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
    | 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
    | 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
    | 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
    | 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
    | 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
    | 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
    | 2040-01-01 | 2040-01-01 00:00:00 | 00000000000000 |
    | 9999-12-31 | 9999-12-31 23:59:59 | 00000000000000 |
    +------------+---------------------+----------------+
    14 rows in set (0.00 sec)

Los dos últimos valores de columna `TIMESTAMP` son cero porque los valores de año (`2040`, `9999`) excede el máximo de `TIMESTAMP`. El tipo de datos `TIMESTAMP` que se usa para almacenar el tiempo actual, soporta valores del rango `19700101000000` hasta `20300101000000` en máquinas de 32-bit (valores con signo). En máquinas de 64-bit, `TIMESTAMP` trata valores hasta `2106` (valores sin signo).

Aunque MySQL Server por sí mismo no tiene problemas con el año 2000, puede tenerlos si interactúa con aplicaciones que sí los tengan. Por ejemplo, muchas aplicaciones antiguas almacenan o manipulan años usando valores de dos dígitos (que son ambíguos) en lugar de cuatro dígitos. Este problema puede darse por aplicaciones que usan valores tales como `00` o `99` como indicadores de valores "perdidos". Por desgracia, estos problemas pueden ser complicados de arreglar, ya que aplicaciones diferentes pueden haber sido programadas por distintos programadores, cada uno de los cuales puede usar una serie de distintas convenciones y funciones de fechas.

Así, aunque MySQL Server no tiene problemas con el año 2000, es la responsabilidad de la aplicación de proporcionar entradas inambíguas. Consulte Sección 11.3.4, “Efecto 2000 (Y2K) y tipos de datos” para las reglas de MySQL Server para tratar fechas ambíguas de dos digitos.

## 1.5. Mapa de desarrollo de MySQL

Esta sección proporciona un vistazo del plan de desarrollo de MySQL, incluyendo las principales características implementadas o planeadas para MySQL 4.0, 4.1, 5.0, y 5.1. La siguiente sección proporciona información para cada serie.

La actual serie en producción es MySQL 5.0, cuya versión estable es la 5.0.9, publicada en agosto del 2005. La serie de producción anterior es la MySQL 4.1, cuya versión estable es 4.1.7, publicada en octubre del 2004. Estatus de producción significa que el futuro del desarrollo 5.0 y 4.1. está limitado sólo a arreglar problemas. Para versiones anteriores a MySQL 4.0 y la serie 3.23, sólo se arreglan bugs críticos.

Desarrollo activo de MySQL actualmente tiene lugar en la serie MySQL 5.1, lo que significa que nuevas características se añaden a la misma.

Antes de actualizar de una serie a la siguiente, por favor consulte los comentarios en Sección 2.10, “Aumentar la versión de MySQL”.

Planes para las características más demandadas se resumen en la siguiente tabla.

Característica | Serie MySQL
Claves foráneas para tablas `MyISAM` | 5.1 (ya implemantado para tablas `InnoDB`)
Disparadores | 5.0 y 5.1
Full outer join | 5.1
Restricciones de integridad | 5.1

### 1.5.1. El servidor MySQL incrustado (embedded)

La biblioteca del servidor incrustado `libmysqld` permite MySQL Server pueda trabajar con una gran cantidad de dominios de aplicaciones. Usando esta biblioteca, los desarrolladores pueden añadir MySQL Server en varias aplicaciones y dispositivos electrónicos, donde el usuario final no tiene conocimiento que hay una base de datos subyacente. MySQL Server incrustado es ideal para uso tras aplicaciones en Internet, kioskos públicos, combinación de hardware/software en llaveros, servidores de alto rendimiento de Internet, bases de datos autocontenidas distribuidas en CD-ROM, y así.

Muchos usuarios de `libmysqld` se benefician de la licencia dual de MySQL. Para los que no quieran estar ligados a la licencia GPL, el software está disponible con licencia comercial. Consulte http://www.mysql.com/company/legal/licensing/ para más información de la política de licencias de MySQL AB. La biblioteca incrustada MySSQL usa la misma interfaz que la biblioteca cliente normal, por lo que es conveniente y fácil de usar. Consulte Sección 24.3.16, “libmysqld, la biblioteca del servidor MySQL incrustado (embedded)”.

En Windows hay dos bibliotecas diferentes:

`libmysqld.lib` | Biblioteca dinámica para aplicaciones threaded.
`mysqldemb.lib` | Biblioteca estático para aplicaciones no threaded.

### 1.5.2. Qué hay de nuevo en MySQL 5.0

Las siguientes características se implementan en MySQL 5.0.

- Tipo de datos BIT: Consulte Sección 11.2, “Tipos numéricos”.

- Cursores: Soporte elemental. Consulte Sección 19.2.11, “Cursores”.

- Diccionario de datos (Information Schema): ConsulteCapítulo 22, La base de datos de información `INFORMATION_SCHEMA`.

- Administrador de instancias: Puede usarse para iniciar y parar el MySQL Server, incluso desde una máquina remota. Consulte Sección 5.2, “El gestor de instancias de MySQL”.

- Matemáticas de precisión: Consulte Capítulo 23, Matemáticas de precisión.

- Procedimientos almacenados: Consulte Capítulo 19, Procedimientos almacenados y funciones.

- Modo estricto y tratamiento de errores estándard: Consulte Sección 5.3.2, “El modo SQL del servidor” y Capítulo 26, Manejo de errores en MySQL.

- Disparadores: Consulte Capítulo 20, Disparadores (triggers).

- Tipo de datos VARCHAR: Soporte nativo `VARCHAR`. La longitud máxima de `VARCHAR` es 65,532 bytes ahora, y no se cortan espacios en blanco consecutivos. Consulte Sección 11.4.1, “Los tipos `CHAR` y `VARCHAR`”.

- Vistas: Consulte Capítulo 21, Vistas (Views) y Sección 1.7.5.6, “Vistas”.

La sección Novedades de este manual incluye una lista más en profundidad de características. Consulte Sección C.1, “Cambios en la entrega 5.0.x (Desarrollo)”.

Para los que deseen consultar las últimas novedades de MySQL, tenemos nuestro repositorio BitKeeper para MySQL disponible públicamente. Consulte Sección 2.8.3, “Instalar desde el árbol de código fuente de desarrollo”.

## 1.6. Fuentes de información acerca de MySQL

### 1.6.1. Listas de correo de MySQL

Esta sección presenta las listas de correo MySQL y proporciona guías sobre cómo deben usarse las listas. Cuando se suscribe a una lista de correo, recibe todos los mensajes como mensajes electrónicos. Puede enviar sus propias preguntas y respuestas a la lista.

#### 1.6.1.1. Las listas de correo de MySQL

Para suscribirse o borrarse de cualquiera de las listas descritas en esta sección, visite http://lists.mysql.com/. Para la mayoría de ellos, puede seleccionar la versión normal de la lista en la que recibe mensajes individuales, o una versión resumida en la que recibe un gran mensaje al día.

Por favor no envíe mensajes para suscribirse o borrarse a ninguna de las listas de correo, ya que dichos mensajes se distribuyen automáticamente a miles de usuarios..

Su sitio local puede tener muchos suscriptores a una lista de correo MySQL. En ese caso, puede tener una lista de correo local, de forma que los mensajes enviados de `lists.mysql.com` a su sitio se propagan a la lista local. En estos casos, por favor contacte con su administrador de sistemas para ser añadido o borrado de la lista MySQL local.

Si desea tener el tráfico de una lista de correo en un buzón de correo separado en su programa de correo, cree un filtro basado en las cabeceras del mensaje. Puede usar las cabeceras `List-ID:` o `Delivered-To:` para identificar los mensajes de la lista.

Las listas de correo de MySQL son las siguientes:

- `anuncios`

  Esta lista es para anuncios de nuevas versiones de MySQL y programas relacionados. Esta es una lista de tráfico bajo y a la que todos los usuarios de MySQL deberían suscribirse.

- `mysql`

  Esta es la lista principal para discusión sobre MySQL en general. Por favor tenga en cuenta que algunas cuestiones es mejor discutirlas en listas más especializadas. Si postea en una lista equivocada, puede no obtener respuesta.

- `bugs`

  Esta lista es para gente que desee estar informada sobre cuestiones reportadas desde la última versión de mySQL o que deseen estar activamente implicadas en el proceso de buscar bugs y arreglarlos. Consulte Sección 1.6.1.3, “Cómo informar de bugs y problemas”.

- `temas internos`

  Esta lista es para gente que trabaja en el código de MySQL. Este también es el fórum para discutir acerca del desarrollo de MySQL y para publicar parches.

- `mysqldoc`

  Esta lista es para gente que trabaja en la documentación de MySQL: gente de MySQL AB, traductores, y otros miembros de la comunidad.

- `pruebas de rendimiento`

  Esta lista es para cualquiera interesado en temas de rendimiento. La discusión se concentra en rendimiento de bases de datos ( no sólo de MySQL), pero también incluye categorías más amplias como rendimiento del kernel, sistema de ficheros, tipos de discos, etc.

- `empaquetadores`

  Esta lista es para discusiones acerca de empaquetar y distribuir MySQL. Este es el fórum usado por mantenedores de distribuciones para intercambiar ideas sobre empaquetar MySQL y asegurar que MySQL parece tan similar como sea posible en todas las plataformas y sistemas operativos soportados.

- `java`

  Esta lista es para discusionse acerca de MySQL Server y Java. Normalmente se usa para discutir acerca de JDBC, incluyendo el connector/J de MySQL.

- `win32`

  Esta lista es para todos los temas acerca del software MySQL en sistemas operativos Microsoft, tales como Windows 9x, Me, NT, 2000, SP y 2003..

- `myodbc`

  Esta lista es para todos los tópicos acerca de conectar al MySQL Server con ODBC.

- `herramientas gui`

  Esta lista es para todos los temas acerca de herramientas GUI MySQL, incluyendo `MySQL Administrator` y el cliente gráfico `MySQL Control Center`.

- `cluster`

  Esta lista es para discusión acerca de MySQL Cluster.

- `dotnet`

  Esta lista es para discusión acerca de MySQL Server y la plataforma .NET. La mayoría de discusiones es acerca del Connector/NET MySQL.

- `plusplus`

  Esta lista es para tópicos acerca de programación con la API C++ para MySQL.

- `perl`

  Esta lista es para tópicos acerca de soporte Perl para MySQL con `DBD::mysql`.

Si no es capaz de obtener una respuesta a su pregunta de ninguna lista MySQL, una opción es adquirir soporte de MySQL AB. Esto le pondrá en contacto directo con los desarrolladores.

La siguiente tabla muestra algunas listas de correo MySQL en idiomas distintos al inglés. Estas listas no son operadas por MySQL AB.

- ``<mysql-france-subscribe@yahoogroups.com>``

  Lista de correo francesa.

- ``<list@tinc.net>``

  Lista de correo Koreana. Envíe un correo a `subscribe mysql your@email.address` para subscribirse a la lista.

- ``<mysql-de-request@lists.4t2.com>``

  Lista de correo Alemana. Envíe un correo a `subscribe mysql-de your@email.address` para subscribirse a la lista. Puede encontrar información acerca de esta lista en http://www.4t2.com/mysql/.

- ``<mysql-br-request@listas.linkway.com.br>``

  Lista de correo Portuguesa. Envíe un correo a `subscribe mysql-br your@email.address` para subscribirse a la lista.

- ``<mysql-alta@elistas.net>``

  Lista de correo Española. Envíe un correo a `subscribe mysql your@email.address` para subscribirse a la lista.

#### 1.6.1.2. Hacer preguntas y reportar bugs

Antes de reportar un bug o cuestión, por favor haga lo siguiente:

- Busque en el manual en línea en http://dev.mysql.com/doc/. Intentamos mantener el manual actualizado añadiendo soluciones a nuevos problemas frecuentemente. El historial de cambios (http://dev.mysql.com/doc/mysql/en/News.html) puede ser particularmente útil ya que es bastante posible que versiones más actuales tengan soluciones a su problema.

- Busque en la base de datos de bugs en http://bugs.mysql.com/ para ver si el bug ha sido reportado y solucionado.

- Busque el archivo de las listas de correo MySQL en http://lists.mysql.com/.

- También puede usar http://www.mysql.com/search/ para buscar en todas las páginas web (incluyendo el manual) que se encuentran en la web de MySQL AB.

Si no puede encontrar una solución en el manual o los archivos, pruebe con su experto local en MySQL. Si tampoco puede encontrar una solución a su pregunta, por favor siga las guías para enviar un correo a las listas de correo MySQL, explicado en la siguiente sección, antes de contactar con nosotros.

#### 1.6.1.3. Cómo informar de bugs y problemas

El sitio normal en el que reportar bugs es http://bugs.mysql.com/, que es la dirección de nuestra base de datos de bugs. Esta base de datos es pública, y puede ser consultada por cualquiera. Si entra en el sistema, puede añadir nuevos reportes.

Para escribir un buen reporte de error se necesita paciencia, pero hacerlo correctamente por primera vez nos ahorra tiempo tanto a nosotros como a usted mismo. Un buen reporte de bug que contenga un testeo completo del bug, hace que sea muy probable que se arregle para la siguiente versión. Esta sección muestra cómo escribir un reporte correctamente de forma que no pierda su tiempo haciendo cosas que no nos ayudan en absoluto.

Animamos a todo el mundo a usar el script mysqlbug para generar un reporte de bug (o un reporte acerca de cualquier problema). mysqlbug puede encontrarse en el directorio `scripts` (distribución fuente) y en el directorio `bin` en el directorio de instalación (distribución binaria). Si no es posible usar mysqlbug (por ejemplo, si utiliza Windows), es vital que incluya toda la información necesaria que aparece en esta sección (y lo más importante, una descripción del sistema operativo y la versión de MySQL).

El script mysqlbug le ayuda a generar un reporte determinando la mayoría de la información automáticamente, pero si falta algo importante, por favor inclúyalo en su mensaje. Por favor, lea esta sección con cuidado y asegúrese que toda la información descrita aquí se incluye en su reporte.

Preferiblemente, debe testear el problema usando la última versión de producción o desarrollo de MySQL server antes de postear. Cualquiera debería ser capaz de repetir el bug usando `mysql test< script_file` en el caso de test incluído o ejecutando el script de consola o Perl incluído en el reporte de bug.

Todos los bugs posteados en la base de datos de bugs en http://bugs.mysql.com/ se corrigen o documentan en la siguiente actualización de MySQL. Si sólo se necesitan cambios menores en el código para arreglarlo, podemos postear un parche para arreglarlo.

Si encuentra un fallo importante de seguridad en MySQL, puede enviar un correo a `<security@mysql.com>`.

Si tiene un reporte de bug repetible, por favor envíelo a la base de datos de bugs en http://bugs.mysql.com/. Tenga en cuenta que incluso en este caso es bueno ejecutar el script mysqlbug antes para reunir información de su sistema. Cualquier bug que seamos capaces de reproducir tiene una alta probabilidad de arreglarse en la siguiente versión de MySQL.

Para reportar otros problemas, puede usar cualquiera de las listas de correo de MySQL.

Recuerde que nos es posible responder un mensaje que contenga demasiada información, pero no si no contiene suficiente. Normalmente se omiten los hechos porque se piensa que se conoce la causa del problema y se asume que algunos detalles no importan. Un buen principio es el siguiente: si duda acerca de explicar algo, hágalo. Es más rápido y menos problemático escribir un par de líneas extra en su reporte que esperar a la respuesta si debemos preguntar algo que no se incluya en el reporte inicial.

Los errores más comunes en los reportes de error son (a) no incluir el número de versión de la distribución MySQL Server usada, y (b) no escribir completamente la plataforma en la está instalado MySQL Server (incluyendo el tipo de plataforma y número de versión). Esta es información altamente relevante, y en el 99% de los casos el reporte de bug es inútil sin ella. Muy a menudo nos preguntas "¿Porqué no me funciona a mí?" Entonces encontramos que la característica reportada no estaba implementada en esa versión de MySQL. A veces el error depende de la plataforma; en esos casos es casi imposible para nosotros arreglar nada sin saber el sistema operativo y el número de versión de la plataforma.

Si ha compilado MySQL del código fuente, recuerde en proporcionar información acerca del compilador, si está relacionada con el problema. A menudo la gente encuentra fallos en los compiladores y cree que el problema está relacionado con MySQL. La mayoría de los compiladores están bajo desarrollo contínuo y mejoran versión a versión, necesitamos saber qué compilador usa. Tenga en cuenta que cada cada problema de compilación debe ser considerado como un bug y reportado como tal.

Es más útil cuando se incluye una buena descripción del problema junto al reporte del bug. Esto es dar un buen ejemplo de todo lo que conduce al problema y describir exactamente el problema en sí. El mejor reporte es el que incluye un ejemplo incluyendo cómo reproducir el problema o bug. Consulte Sección D.1.6, “Crear un caso de prueba tras haber encontrado una tabla corrupta”.

Si un programa produce un mensaje de error es muy importante incluirlo en el reporte. Si tratamos de buscar algo de los archivos usando programas, es mejor que el mensaje de error coincida exactamente con el producido por el programa (incluso es importante respetar mayúsculas y minúsculas). Nunca debe intentar reproducir de memoria el mensaje de error; en lugar de ello, copie el mensaje entero en el reporte.

Si tiene algún problema con el Connector/ODBC (MyODBC), por favor trate de generar un fichero de traza y enviarlo con su reporte. Consulte Sección 25.1.7.2, “How to Report Connector/ODBC Problems or Bugs”.

Por favor, recuerde que mucha gente que lea su reporte lo hará con un monitor de 80 columnas. Cuando genere reportes o ejemplos usando la columna de línea de comandos mysql debe usar la opción `--vertical` (o el terminador de comando `\G` ) para salida que excedería el ancho disponible para tales monitores ( por ejemplo, con el comando `EXPLAIN SELECT`; ( vea el ejemplo al final de esta sección).

Por favor, incluya la siguiente información en su reporte:

- 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”.

Si es un cliente con soporte, por favor envíe el reporte de error a `<mysql-support@mysql.com>` para tratamiento de alta prioridad, así como a la lista de correo apropiada para ver si alguien más ha experimentado ( y quizás resuelto ) el problema.

Para información acerca de reportar errores en MyODBC, consulte Sección 25.1.7.2, “How to Report Connector/ODBC Problems or Bugs”.

Para soluciones de problemas más comunes, consulte Apéndice A, Problemas y errores comunes.

Cuando se envían soluciones a usted individualmente y no a la lista de correo, se considera una buena práctica resumir las respuestas y enviar el resumen a la lista de correo, de forma que otros puedan beneficiarse de las respuestas que ha recibido y que le han ayudado a resolver su problema.

#### 1.6.1.4. Guía para la contestación de preguntas en las listas de correo

Si considera que su respuesta tiene interés general, puede postearla en la lista de correo en lugar de responder directamente al indivíduo que la preguntó. Trate de hacer su respuesta general para que otras personas a parte de quién hizo la pregunta, se puedan beneficiar con la respuesta otros usuarios. Cuando postee a la lista, aségurese que su respuesta no es una duplicación de otra respuesta.

Trate de resumir la parte esencial de la pregunta en su respuesta; no se sienta obligado a anotar el mensaje original entero.

Por favor, no postee un mensaje desde su navegador con el modo HTML activado. Muchos usuarios no leen el correo con un navegador

### 1.6.2. Soporte por IRC (Internet Relay Chat) de la comunidad MySQL

Adicionalmente a las listas de correo MySQL, puede encontrar una comunidad experimentada en `IRC` (`Internet Relay Chat`). Estos son los mejores canales que conocemos hoy día:

- freenode (consulte http://www.freenode.net/ para servidores)

  - `#mysql` Básicamentes preguntas sobre MySQL , pero también de otras bases de datos y preguntas generales sobre SQL. Preguntas sobre PHP, Perl o C en combinación con MySQL son frecuentes.

Si busca un cliente IRC para conectar a un canal IRC, consulte `X-Chat` (http://www.xchat.org/). X-Chat (GPL licensed) está disponible para Unix así como para Windows (una implementación libre para Windows sobre X-Chat está disponible en http://www.silverex.org/download/).

### 1.6.3. Soporte por parte de la comunidad en los foros de MySQL

El último recurso de soporte para la comunidad son los foros en http://forums.mysql.com.

Hay una variedad de foros disponibles, agrupados en las siguientes categorías generales:

- Migración

- Uso de MySQL

- Conectores MySQL

- Tecnología MySQL

- Negocios

## 1.7. Cumplimiento de los estándares por parte de MySQL

Esta sección describe cómo MySQL se relaciona con el estándard ANSI/ISO SQL. MySQL Server tiene varias extensiones del estándard SQL, y aquí puede encontrar cuáles son y cómo usarlas. También puede encontrar información sobre lagunas de funcionalidades en MySQL Server, y cómo tratar algunas diferencias.

El estándard SQL ha ido evolucionando desde 1986 y existen varias versiones. En este manual, "SQL-92" se refiere al estándard publicado en 1992, "SQL:1999" se refiere al estándard publicado en 1999, y "SQL:2003" se refiere a la versión actual del estándard. Usamos la frase "el estándard SQL" para referirnos a la versión actual del estándard SQL en cualquier momento.

Nuestro objetivo es no restringir la usabilidad de MySQL ningún uso sin una muy buena razón para ello. Incluso si no tenemos los recursos para hacer un desarrollo para cada uso posible, estamos siempre deseando ayudar y ofrecer sugerencias a gente que intenta usar MySQL en nuevos campos.

Uno de nuestros fines principales con el producto es continuar el trabajo hacia el cumplimiento del estándard SQL, pero sin sacrificar velocidad o fiabilidad. No tememos añadir extensiones a SQL o soporte para funcionalidades no SQL si esto aumenta la usabilidad de MySQL Server para un gran segmento de nuestra base de usuarios. La interfaz `HANDLER` en MySQL Server 4.0 es un ejemplo de esta estrategia. Consulte Sección 13.2.3, “Sintaxis de `HANDLER`”.

Continuamos soportando bases de datos transaccionales y no transaccionales para satisfacer uso crítico 24/7 y uso pesado en entornos Web o log.

MySQL Server fue diseñado originalmente para trabajar con bases de datos de tamaño medio (de 10 a 100 millones de regitros, o unas 100MB por tabla) en máquinas pequeñas. Hoy MySQL Server soporta bases de datos de tamaño de terabytes, pero el código todavía puede compilarse en una versión reducida adecuada para dispositivos hand-held o incrustados. El diseño compacto de MySQL Server hace el desarrollo en ambas direcciones posible sin ningún conflicto en el árbol fuente.

Actualmente, no tratamos soporte en tiempo real, aunque la capacidad de replicación en MySQL ofrece funcionalidades significativas.

Existe soporte para clusters de bases de datos a través de soluciones de terceras partes, así como la integración de tecnología NDB Cluster, disponible desde la versión 4.1.2. Consulte Capítulo 16, MySQL Cluster.

También estamos mirando de proveer de soporte XML en el servidor de base de datos.

### 1.7.1. Estándares utilizados por MySQL

Estamos intentando soportar en estándard ANSI/ISO completamente, pero sin hacer concesiones a la velocidad y calidad del código.

Niveles ODBC 0-3.51.

### 1.7.2. Selección de modos SQL

MySQL Server puede operar en distintos modos SQL y puede aplicar dichos modos de forma diferente para distintos clientes. Esto permite a una aplicación adaptar el funcionamiento del servidor a sus propios requerimientos.

Los modos definen la sintaxis que MySQL debe soportar y qué clase de validaciones debe efectuar a los datos. Esto hace más fácil usar MySQL en un conjunto de entornos diferentes y usar MySQL junto con otros servidores de bases de datos.

Puede inicializar el modo SQL por defecto inicializando mysqld con la opición `--sql-mode="modes"`. Empezando en MySQL 4.1., se puede cambiar el modo tras inicializar mediante la variable `sql_mode` con un comando `SET [SESSION|GLOBAL] sql_mode='modes'`.

Para más información acerca de especificar el modo del servidor, consulte Sección 5.3.2, “El modo SQL del servidor”.

### 1.7.3. Ejecutar MySQL en modo ANSI

Puede decirle a mysqld que use el modo ANSI con la opción `--ansi` al arrancar. Consulte Sección 5.3.1, “Opciones del comando mysqld”.

Ejecutar el servidor en modo ANSI es lo mismo que inicializarlo con las siguientes opciones (especifique el valor de `--sql_mode` en una única línea):

    --transaction-isolation=SERIALIZABLE
    --sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
    IGNORE_SPACE

En MySQL 4.1, puede conseguir el mismo efecto con los siguientes 2 comandos (especifique el valor de `sql_mode` en una única línea):

    SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
    SET GLOBAL sql_mode = 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
    IGNORE_SPACE';

Consulte Sección 1.7.2, “Selección de modos SQL”.

En MySQL 4.1.1, la opción `sql_mode` puede inicializarse con el siguiente comando:

    SET GLOBAL sql_mode='ansi';

En ese caso, el valor de la variable `sql_mode` se especifica para todas las opciones que son relevantes en el modo ANSI. Puede comprobar el resultado de la siguiente manera:

    mysql> SET GLOBAL sql_mode='ansi';
    mysql> SELECT @@global.sql_mode;
            -> 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
                IGNORE_SPACE,ANSI';

### 1.7.4. Extensiones MySQL al estándar SQL

MySQL Server incluye algunas extensiones que probablemente no encontrará en otras bases de datos SQL. Tenga en cuenta que si lo usa, su código no será portable a otros servidores SQL. En algunos casos, puede escribir código que incluya extensiones MySQL, pero siendo portable, mediante comentarios de la forma `/*! ... */`. En ese caso, MySQL parsea y ejecuta el código dentro de los comentarios como si fuera cualquier otro comando de MySQL, pero otros servidores SQL ignorarán la extensión. Por ejemplo:

    SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...

Si añade un número de versión tras el carácter '`!`', la sintaxis dentro del comentario se ejecuta sólo si el número de versión de MySQL es igual o mayor que el especificado:

    CREATE /*!32302 TEMPORARY */ TABLE t (a INT);

Eso significa que si tiene la Versión 3.23.02 o posterior, MySQL Server usa la palabra clave `TEMPORARY`.

La siguiente lista describe las extensiones MySQL, organizadas por categorías.

- Organización de los datos en disco

  MySQL Server mapea cada base de datos a un directorio bajo el directorio de datos de MySQL, y las tablas dentro de cada directorio como ficheros. Esto tiene algunas implicaciones:

  - Nombres de bases de datos y nombres de tablas son case sensitive en MySQL Server en sistemas operativos que tienen nombres de ficheros case-sensitive (como la mayoría de sistemas Unix). Consulte Sección 9.2.2, “Sensibilidad a mayúsuclas y minúsculas de identificadores”.

  - Puede usar comandos de sistema estándard para hacer copia de seguridad, renombrar, mover, borrar y copiar tablas de tipo `MyISAM` o `ISAM`. Por ejemplo, para renombrar el nombre de una tabla `MyISAM` renombre los archivos `.MYD`, `.MYI`, y `.frm` que correspondan a la tabla.

  Nombres de bases de datos, tablas, índices, columnas o alias pueden empezar con un dígito (pero no pueden consistir únicamente de dígitos).

- Sintaxis general del lenguaje

  - Cadenas de carácteres deben limitarse por '`"`' o '`'`', no sólo por '`'`'.

  - Use '`\`' como un carácter de escape en cadenas de carácteres.

  - En comandos SQL, puede acceder a tablas de distintas bases de datos con la sintaxis `db_name.tbl_name`. Algunos servidores SQL proporcionan la misma fucnionalidad, pero lo llaman `User space`. MySQL Server no soporta espacios de tablas como los usados en comandos como: `CREATE TABLE ralph.my_table...IN my_tablespace`.

- Sintaxis de comandos SQL

  - Los comandos `ANALYZE TABLE`, `CHECK TABLE`, `OPTIMIZE TABLE`, y `REPAIR TABLE`.

  - Los comandos `CREATE DATABASE` y `DROP DATABASE`. Consulte Sección 13.1.3, “Sintaxis de `CREATE DATABASE`”.

  - El comando `DO`.

  - `EXPLAIN SELECT` para obtener una descripción de cómo las tablas se usan.

  - Los comandos `FLUSH` y `RESET`.

  - El comando `SET`. Consulte Sección 13.5.3, “Sintaxis de `SET`”.

  - El comando `SHOW`. Consulte Sección 13.5.4, “Sintaxis de `SHOW`”.

  - Uso de `LOAD DATA INFILE`. En muchos casos, esta sintaxis es compatible con el comando de Oracle `LOAD DATA INFILE`. Consulte Sección 13.2.5, “Sintaxis de `LOAD DATA INFILE`”.

  - Uso de `RENAME TABLE`. Consulte Sección 13.1.9, “Sintaxis de `RENAME TABLE`”.

  - Uso de `REPLACE` en lugar de `DELETE` + `INSERT`. Consulte Sección 13.2.6, “Sintaxis de `REPLACE`”.

  - Uso de `CHANGE col_name`, `DROP col_name`, o `DROP INDEX`, `IGNORE` o `RENAME` en un comando `ALTER TABLE`. Uso de múltiples `ADD`, `ALTER`, `DROP`, o `CHANGE` cláusulas en un comando `ALTER TABLE`. Consulte Sección 13.1.2, “Sintaxis de `ALTER TABLE`”.

  - Uso de nombres de índices, índices sobre el prefijo de un cambio, y uso de `INDEX` o `KEY` en un comando `CREATE TABLE`. Consulte Sección 13.1.5, “Sintaxis de `CREATE TABLE`”.

  - Uso de `TEMPORARY` o `IF NOT EXISTS` con `CREATE TABLE`.

  - Uso de `IF EXISTS` con `DROP TABLE`.

  - Puede borrar varias tablas con un único comando `DROP TABLE`.

  - Las cláusulas `ORDER BY` y `LIMIT` de los comandos `UPDATE` y `DELETE`.

  - Sintaxis de `INSERT INTO ... SET col_name = ...`.

  - La cláusula `DELAYED` de los comandos `INSERT` y `REPLACE`.

  - La cláusula `LOW_PRIORITY` de los comandos `INSERT`, `REPLACE`, `DELETE`, y `UPDATE`.

  - Uso de `INTO OUTFILE` y `STRAIGHT_JOIN` en un comando `SELECT` . Consulte Sección 13.2.7, “Sintaxis de `SELECT`”.

  - La opción `SQL_SMALL_RESULT` en un comando `SELECT`.

  - No necesita nombrar todas las columnas seleccionadas en la parte `GROUP BY`. Esto proporciona mejor rendimiento en algunas consultas muy específicas pero bastante normales. Consulte Sección 12.10, “Funciones y modificadores para cláusulas `GROUP BY`”.

  - Puede especificar `ASC` y `DESC` con `GROUP BY`.

  - La habilidad para inicializar variables en un comando con el operador `:=`:

        mysql> SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg
            -> FROM test_table;
        mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;

- Tipos de columnas

  - Los tipos de columnas `MEDIUMINT`, `SET`, `ENUM`, y los distintos tipos `BLOB` y `TEXT`.

  - Los atributos de columnas `AUTO_INCREMENT`, `BINARY`, `NULL`, `UNSIGNED`, y `ZEROFILL`.

- Funciones y operadores

  - Para facilitar a los usuarios que vienen de otros entornos SQL, MySQL Server soporta alias para varias funciones. Por ejemplo, todas las funciones de cadenas de carácteres soportan sintaxis estándard SQL y ODBC.

  - MySQL Server entiende los operadores `||` y `&&` para OR lógica y AND, como en el lenguaje de programación C. En MySQL Server, `||` y `OR` son sinónimos, como lo son `&&` y `AND`. Debido a esta sintaxis, MySQL Server no soporta el operador estándard SQL `||` para concatenar cadenas de carácteres; use en su lugar `CONCAT()`. Como `CONCAT()` toma cualquier número de argumentos, es fácil adaptarse al uso del operador `||` a MySQL Server.

  - Uso de `COUNT(DISTINCT list)` donde `list` tiene más de un elemento.

  - Todas las comparaciones de cadenas de carácteres son case-insensitive por defecto, con la ordenación determinada por el conjunto de carácteres actual (ISO-8859-1 Latin1 por defecto). Si no quiere que sea así, puede declarar las columnas con el atributo `BINARY` o usar la conversión `BINARY`, que hace que las comparaciones se hagan usando el código de carácteres subyacente en lugar del orden léxico.

  - El operador `%` es sinónimo de `MOD()`. Esto es que `N % M` es equivalente a `MOD(N,M)`. `%` se soporta para programadores C y por compatibilidad con PostgreSQL.

  - Los operadores `=`, `<>`, `<=` ,`<`, `>=`,`>`, `<<`, `>>`, `<=>`, `AND`, `OR`, o `LIKE` se pueden usar en comparaciones de columnas a la izquierda del `FROM` en comandos `SELECT`. Por ejemplo:

        mysql> SELECT col1=1 AND col2=2 FROM tbl_name;

  - La función `LAST_INSERT_ID()` retorna el valor `AUTO_INCREMENT` más reciente. Consulte Sección 12.9.3, “Funciones de información”.

  - `LIKE` se permite en columnas numéricas.

  - Los operadores de expresiones regulares extendidos `REGEXP` y `NOT REGEXP`.

  - `CONCAT()` o `CHAR()` con un argumento o más de dos argumentos. (En MySQL Server, estas funciones pueden tomar cualquier número de argumentos.)

  - Las funciones `BIT_COUNT()`, `CASE`, `ELT()`, `FROM_DAYS()`, `FORMAT()`, `IF()`, `PASSWORD()`, `ENCRYPT()`, `MD5()`, `ENCODE()`, `DECODE()`, `PERIOD_ADD()`, `PERIOD_DIFF()`, `TO_DAYS()`, y `WEEKDAY()`.

  - Uso de `TRIM()` para eliminar espacios en substrings. Funciones estándard sólo SQL soportan eliminar carácteres simples.

  - Las funciones `GROUP BY` `STD()`, `BIT_OR()`, `BIT_AND()`, `BIT_XOR()`, y `GROUP_CONCAT()`. Consulte Sección 12.10, “Funciones y modificadores para cláusulas `GROUP BY`”.

### 1.7.5. Diferencias en MySQL del estándar SQL

Intentamos que MySQL Server siga los estándares ANSI SQL y el estándard ODBC SQL, pero MySQL Server ejecuta operaciones de forma distinta en algunos casos:

- Para columnas `VARCHAR`, los espacios finales se eliminan cuando el valor se guarda. (Arreglado en MySQL 5.0.3). Consulte Sección A.8, “Problemas conocidos en MySQL”.

- En algunos casos, las columnas de tipo `CHAR` se convierten en columnas `VARCHAR` cuando define una tabla o altera su estructura. (Arreglado en MySQL 5.0.3). Consulte Sección 13.1.5.1, “Cambios tácitos en la especificación de columnas”.

- Los privilegios para una tabla no se eliminan automáticamente cuando se borra una tabla. Debe usar explícitamente un comando `REVOKE` para quitar los privilegios de una tabla. Consulte Sección 13.5.1.3, “Sintaxis de `GRANT` y `REVOKE`”.

- La función `CAST()` no soporta conversión a `REAL` o `BIGINT`. Consulte Sección 12.8, “Funciones y operadores de cast”.

- SQL estándard necesita que las cláusulas `HAVING` en un comando `SELECT` puedan referirse a columnas en la cláusula `GROUP BY`. Esto no se permite antes de la versión MySQL 5.0.2.

#### 1.7.5.1. Subconsultas

MySQL 4.1 soporta sub-consultas y tablas derivadas. Una "sub-consulta" es un comando `SELECT` anidado en otro comando. Una tabla "derivada" (una vista sin nombre) es una subconsulta en la cláusula `FROM` de otra consulta. Consulte Sección 13.2.8, “Sintaxis de subconsultas”.

Para versiones MySQL anteriores a la 4.1, la mayoría de subconsultas pueden reescribirse usando joins u otros métodos. Consulte Sección 13.2.8.11, “Re-escribir subconsultas como joins en versiones de MySQL anteriores” para ejemplos que muestren cómo hacerlo.

#### 1.7.5.2. `SELECT INTO TABLE`

MySQL Server no soporta la sintaxis de extensiones Sybase SQL: `SELECT ... INTO TABLE ...`. En su lugar, MySQL Server soporta la sintaxis estándard SQL `INSERT INTO ... SELECT ...`, que básicamente es lo mismo. Consulte Sección 13.2.4.1, “Sintaxis de `INSERT ... SELECT`”.

    INSERT INTO tbl_temp2 (fld_id)
        SELECT tbl_temp1.fld_order_id
        FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;

Alternativamente, puede usar `SELECT INTO OUTFILE ...` o `CREATE TABLE ... SELECT`.

Para al versión 5.0, MySQL soporta `SELECT ... INTO` con variables de usuario. La misma sintaxis puede usarse dentro de procedimientos almacenados usando cursores y variables locales. Consulte Sección 19.2.9.3, “La sentencia `SELECT ... INTO`”.

#### 1.7.5.3. Transacciones y operaciones atómicas

MySQL Server (versiones 3.23-max y todas las versiones 4.0 y posteriores) soportan transacciones con los motores trasaccionales `InnoDB` y `BDB` . `InnoDB` proporciona completa compatibilidad `ACID`. Consulte Capítulo 14, Motores de almacenamiento de MySQL y tipos de tablas.

Los otros motores no transaccionales en MySQL Server (como `MyISAM`) siguen un paradigma diferente para integridad de datos llamado "operaciones atómicas". En términos transaccionales, tablas `MyISAM` operan en modo `AUTOCOMMIT=1`. Operaciones atómicas a menudo ofrecen integridad comparable con mejor rendimiento.

MySQL Server soporta ambos paradigmas, puede decidir si su aplicación necesita la velocidad de operaciones atómicas o el uso de características transaccionales. Esta elección puede hacerse para cada tabla.

Como se ha dicho, el compromiso entre tipos de tablas transaccionales y no transaccionales reside principalmente en el rendimiento. Tablas transaccionales tienen requerimientos significativamente mayores para memoria y espacio de disco, y mayor carga de CPU. Por otra parte, tipos de tablas transaccionales como `InnoDB` también ofrece muchas características significativas. El diseño modular de MySQL Server permite el uso concurrente de distintos motores de almacenamiento para cumplir distintos requerimientos y mostrarse óptimo en todas las situaciones.

Pero, ¿cómo usar las características de MySQL Server para mantener integridad de forma rigurosa incluso en tablas no transaccionales como `MyISAM` , y cómo se comparan estas características con los tipos de tablas transaccionales?

1. Si su aplicación está escrita de forma que dependa en que pueda llamar a `ROLLBACK` en lugar de `COMMIT` en situaciones críticas, es preferible usar transacciones. Transacciones aseguran que actualizaciones no acabadas o actividades corruptas no se ejectuen en la base de datos; el servidor tiene la oportunidad de hacer un rollback automático para mantener la base de datos a salvo.

   Si usa tablas no transaccionales, MySQL Server le permite solucionar problemas potenciales en prácticamente todos los casos simplemente incluyendo chequeos antes de las actualizaciones y ejecutando scripts sencillos que comprueban que la consistencia de la base de datos, dando una advertencia o reparando automáticamente cualquier incosistencia. Simplemente usando el log de MySQL o añadiendo un log extra, normalmente puede arreglar tablas sin pérdida de integridad en los datos.

2. Normalmente, las actualizaciones transaccionales críticas pueden reescribirse como atómicas.Generalmente hablando, todos los problemas de integridad que resuelven las transacciones pueden resolverse con `LOCK TABLES` o actualizaciones atómicas, asegurando que no se aborten automáticamente desde el servidor, el cuál es un problema habitual en sistemas de bases de datos transaccionales.

3. Para tener un entorno fiable de MySQL, usando tablas transaccionales o no, sólo necesita tener copias de seguridad y el log binario activado. Con ello, puede recuperarse de cualquier situación de la que pueda hacerlo con cualquier otro sistema transaccional. Siempre es bueno tener copias de seguridad, independientemente del sistema de bases de datos usado.

El paradigma transaccional tiene sus ventajas y desventajas. Muchos usuarios y desarrolladores de aplicaciones dependen en la facilidad con la que pueden solucionar problemas donde un aborto parece ser o es necesario. Sin embargo, incluso si el paradigma de operaciones atómicas le es desconocido o está más familiarizado con las transacciones, considere el beneficio de la velocidad que pueden ofrecer las tablas no transaccionales, que puede ser de tres a cinco veces más rápido que las más optimizadas tablas transaccionales.

En las situaciones en las que la integridad es de máxima importancia, MySQL Server ofrece integridad a nivel de transacción incluso para tablas no transaccionales. Si bloquea tablas con `LOCK TABLES`, todas las actualizaciones se bloquean hasta que se hacen las comprobaciones necesarias. Si obtiene un bloqueo `READ LOCAL` (el contrario a un bloqueo de escritura) para una tabla que permita inserciones concurrentes al final de la tabla, las lecturas están permitidas, así como las inserciones de otros clientes. Los registros insertados no puede verlos el cliente que tenga el bloqueo hasta que lo libere. Con `INSERT DELAYED`, puede encolar inserciones en una cola local, hasta que los bloqueos se liberan, sin tener que esperar el cliente a que acabe la inserción. Consulte Sección 13.2.4.2, “Sintaxis de `INSERT DELAYED`”.

"Atómico", en el sentido en que nos referimos, no es nada mágico. Se trata que puede asegurar que mientras cada actualización específica está ejecutándose, ningún otro usuario puede interferir con ellas, y que nunca puede haber un rollback automático (lo que puede ocurrir con tablas transaccionales si no se es muy cuidadoso). MySQL Server garantiza que no hay dirty reads (lecturas sucias).

A continación se presentan algunas técnicas para trabajar con tablas no transaccionales:

- Los bucles que necesiten transacciones normalmente pueden codificarse con la ayuda de `LOCK TABLES`, y no necesita cursores para actualizar registros en tiempo real.

- Para evitar usar `ROLLBACK`, puede usar la siguiente estrategia:

  1. Use `LOCK TABLES` para bloquear todas las tablas a las que quiere acceder.

  2. Compruebe las condiciones que deben darse antes de ejecutar la actualización.

  3. Actualice si todo es correcto.

  4. Use `UNLOCK TABLES` para liberar los bloqueos.

  Este es un método mucho más rápido que usar transacciones con posibles rollbacks, aunque no siempre. La única situación en que esta situación no funciona es cuando alguien mata el thread durante una actualización. En ese caso, todos los bloqueos se liberan pero algunas actualizaciones pueden no ejecutarse.

- Puede usar funciones para actualizar registros en una única operación. Puede obtener una aplicación muy eficiente usando las siguientes técnicas:

  - Modifique columnas con su valor actual.

  - Actualice sólo aquéllas que hayan cambiado.

  Por ejemplo, cuando estamos actualizando la información de un cliente, sólo actualizamos los datos del cliente que han cambiado y comprobamos que los datos cambiados o datos que dependen de los datos cambiados, han cambiado respecto a los datos originales. El test para datos cambiados se hace con la cláusula `WHERE` en el comando `UPDATE` . Si el registro no se ha actualizado, mostramos un mensaje al cliente: "Algunos de los datos actualizados han sido cambiados por otro usuario". A continuación mostramos los registros viejos junto a los nuevos en una ventana para que el usuario pueda decidir qué versión del registro de usuario usar.

  Esto nos da algo que es similar a bloqueo de columnas pero es incluso mejor ya que sólo actualizamos algunas de las columnas, usando valores que son relativos a sus valores actuales. Eso significa que el típico comando `UPDATE` será algo así:

      UPDATE tablename SET pay_back=pay_back+125;

      UPDATE customer
        SET
          customer_date='current_date',
          address='new address',
          phone='new phone',
          money_owed_to_us=money_owed_to_us-125
        WHERE
          customer_id=id AND address='old address' AND phone='old phone';

  Esto es muy eficiente y funciona incluso si otro cliente ha cambiado los valores en las columnas `pay_back` o `money_owed_to_us`.

- En muchos casos, los usuarios han querido usar `LOCK TABLES` y/o `ROLLBACK` con la intención de administrar identificadores únicos. Se puede tratar de forma mucho más eficiente sin bloquear o rolling back usando columnas `AUTO_INCREMENT` y la función SQL `LAST_INSERT_ID()` o la función de la API C `mysql_insert_id()`. Consulte Sección 12.9.3, “Funciones de información”. Consulte Sección 24.3.3.34, “`mysql_insert_id()`”.

  Normalmente puede codificar la necesidad de bloqueo a nivel de registro. Algunas situaciones realmente lo necesitan, y las tablas `InnoDB` lo soportan. Con tablas `MyISAM`, puede usar una columna flag en la tabla y hacer algo como lo siguiente:

      UPDATE tbl_name SET row_flag=1 WHERE id=ID;

  MySQL retorna `1` para el número de registros afectados si la fila ha sido encontrada y `row_flag` no era `1` en el registro original.

  Puede imaginarlo como si MySQL Server cambiase la consulta anterior a:

      UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;

#### 1.7.5.4. Procedimientos almacenados (stored procedures) y disparadores (triggers)

Los procedimientos almacenados se implementan desde la versión 5.0. Consulte Capítulo 19, Procedimientos almacenados y funciones.

Funcionalidad básica para disparadores se implementa en MySQL desde la versión 5.0.2, con desarrollo adicional planeado para MySQL 5.1. Consulte Capítulo 20, Disparadores (triggers).

#### 1.7.5.5. Claves foráneas (foreign keys)

En MySQL Server 3.23.44 y posteriores, el motor `InnoDB` soporta chequeo para restricciones de claves foráneas, incluyendo `CASCADE`, `ON DELETE`, y `ON UPDATE`. Consulte Sección 15.6.4, “Restricciones (constraints) `FOREIGN KEY`”.

Para otros motores diferentes a `InnoDB`, MySQL Server parsea la sintaxis de `FOREIGN KEY` en comandos `CREATE TABLE`, pero no lo usa ni almacena. En el futuro, la implemantación se extenderá para almacenar esta información en el fichero de especificaciones de las tablas de forma que puedan obtenerla mysqldump y ODBC. En una etapa posterior, restricciones de claves foráneas se implementarán para tablas `MyISAM`.

Restricciones de claves foráneas ofrecen distintos beneficios a los diseñadores de bases de datos:

- Suponiendo un diseño adecuado de las relaciones, las restricciones de claves foráneas hacen más difícil que un programador introduzca inconsistencias en la base de datos.

- Chequeo centralizado de restricciones por el servidor de base de datos hace que sea innecesario realizar esos chequeos en la parte de la aplicación, eliminando la posibilidad que distintas aplicaciones puedan no chequear todas las restricciones de la misma forma.

- Usando actualizaciones y borrados en cascada puede simplificarse el código de aplicación.

- Reglas diseñadas correctamente para claves foráneas pueden ayudar a documentar las relaciones entre tablas.

Tenga en cuenta que estos beneficios tienen el coste de un trabajo adicional para el servidor de base de datos para poder realizar todas las comprobaciones necesarias. Chequeos adicionales por parte del servidor afectan al rendimiento, lo que puede ser lo suficientemente malo para algunas aplicaciones como para evitarlo todo lo posible. (Algunas grandes aplicaciones comerciales han codificado la lógica de claves foráneas en el nivel de aplicación por esta razón.)

MySQL proporciona a diseñadores de bases de datos la posibilidad de elegir qué paradigma elegir. Si no necesita claves foráneas y quiere evitar la sobrecarga asociada con la integridad referencial, puede usar otro tipo de tabla como `MyISAM`. (Por ejemplo, el motor `MyISAM` ofrece muy buen rendimiento para aplicaciones que sólo realizan operaciones `INSERT` y `SELECT`, ya que las inserciones de pueden utilizar de forma concurrente con consultas. Consulte Sección 7.3.2, “Cuestiones relacionadas con el bloqueo (locking) de tablas”.)

Si elige no utilizar integridad referencial, tenga en cuenta las siguientes consideraciones:

- Sin un chequeo por parte del servidor de integridad referencial, la aplicación debe realizar este trabajo. Por ejemplo, debe tener cuidado de insertar registros en tablas en el orden apropiado, y evitar crear registros con hijos huérfanos. También debe ser capaz de recuperarse de errores que ocurran durante inserciones múltiples.

- Si `ON DELETE` es la única integridad referencial que necesita la aplicación, desde la versión 4.0 de MySQL Server puede usar comandos `DELETE` para borrar registros de distintas tablas con un único comando. Consulte Sección 13.2.1, “Sintaxis de `DELETE`”.

- Una forma de suplir la falta de `ON DELETE` es añadir el comando `DELETE` apropiado a su aplicación cuando borre registros de una tabla que no tenga clave foránea. En la práctica, esto es tan rápido como usar una clave foránea, y más portable.

Tenga en cuenta que el uso de claves foráneas puede provocar algunos problemas:

- El soporte de claves foráneas arregla muchas cuestiones relacionadas con la integridad, pero todavía es necesario diseñar las claves cuidadosamente para evitar reglas circulares o combinaciones incorrectas de borrados en cascada.

- Es posible crear una topología de relaciones que haga difícil restaurar tablas individuales de una copia de seguridad. (MySQL alivia esta dificultad permitiendo desactivar claves foráneas temporalmente al recargar una tabla que dependa de otras. Consulte Sección 15.6.4, “Restricciones (constraints) `FOREIGN KEY`”. Desde MySQL 4.1.1, mysqldump genera ficheros que utilizan esta características automáticamente al recargarse.)

Tenga en cuenta que las claves foráneas en SQL se usan para chequear y forzar integridad referencial, no para unir tablas. Si quiere obtener resultados de múltiples tablas a partir de un comando `SELECT`, debe usar un join entre ellas:

    SELECT * FROM t1, t2 WHERE t1.id = t2.id;

Consulte Sección 13.2.7.1, “Sintaxis de `JOIN`”. Consulte Sección 3.6.6, “Usar claves foráneas (foreign keys)”.

La sintaxis de `FOREIGN KEY` sin `ON DELETE ...` se usa a menudo por aplicaciones ODBC para producir cláusulas `WHERE` automáticamente.

#### 1.7.5.6. Vistas

Vistas (incluyendo vistas actualizables) se implementan en la versión 5.0 de MySQL Server. Las vistas están disponibles en las versiones binarias a partir de la 5.0.1. Consulte Capítulo 21, Vistas (Views).

Las vistas son útiles para permitir acceder a los usuarios a un conjunto de relaciones (tablas) como si fueran una sola, y limitar su acceso a las mismas. También se pueden usar las vistas para restringir el acceso a registros (un subconjunto de una tabla particular). Para control de acceso a columnas, puede usar el sofisticado sistema de privilegios de MySQL Server. Consulte Sección 5.6, “El sistema de privilegios de acceso de MySQL”.

Al diseñar la implementación de las vistas, nuestro ambicioso objetivo, dentro de los límites de SQL, ha sido la plena compatibilidad con la regla 6 de Codd para sistemas relacionales de bases de datos: "Todas las vistas que son actualizables en teoría, deben serlo en la práctica".

#### 1.7.5.7. Empezar un comentario con '`--`'

Algunas otras bases de datos SQL utilizan '`--`' para comenzar comentarios. MySQL Server utiliza '`#`' como carácter para comenzar comentarios. Puede utilizar comentarios estilo C `/*this is a comment */` con MySQL Server. Consulte Sección 9.5, “Sintaxis de comentarios”.

MySQL Server 3.23.3 y posteriores permiten comentarios del estilo '`--`', mientras el comentario esté seguido de un carácter (o por un carácter de controlo como una nueva línea). Se necesita dicho espacio para evitar problemas con consultas SQL generadas automáticamente que usen algo parecido al código a continuación, donde se inserta automáticamente el valor de pago para `!payment!`:

    UPDATE account SET credit=credit-!payment!

Piense acerca de lo que ocurre si el valor de `payment` es un valor negativo como `-1`:

    UPDATE account SET credit=credit--1

`credit--1` es una expresión legal en SQL, pero si `--` se interpreta como parte de un comentario, una parte de la expresión se descarta. El resultado es un comando que tiene un significado completamente distinto al deseado:

    UPDATE account SET credit=credit

Este comando no produce ningún cambio en absoluto! Lo cual ilustra que permitir comentaros que empiecen con '`--`' puede tener serias consecuencias.

Usando la implementación de este método de comentarios en MySQL Server desde 3.23.3, `credit--1` es seguro.

Otra medida de seguridad es que el cliente de líneas de comando mysql elimina todas las líneas que empiecen con '`--`'.

La siguiente información sólo es relevante si utiliza versiones anteriores a la 3.23.3:

Si tiene un programa SQL en un fichero de texto que contenga comentarios del estilo '`--`', debería utilizar la utilidad replace para convertir los comentarios antiguos en carácteres '`#`' de la siguiente forma:

    shell> replace " --" " #" < text-file-with-funny-comments.sql \
             | mysql db_name

en lugar del usual:

    shell> mysql db_name < text-file-with-funny-comments.sql

También puede editar el fichero "a mano" para cambiar los comentarios '`--`' a '`#`':

    shell> replace " --" " #" -- text-file-with-funny-comments.sql

Vuelva a cambiarlos con el comando:

    shell> replace " #" " --" -- text-file-with-funny-comments.sql

### 1.7.6. Cómo trata MySQL las restricciones (Constraints)

MySQL le permite trabajar con tablas transaccionales, que permiten hacer un rollback, y con tablas no transaccionales que no lo permiten. Es por ello que las restricciones son algo distintas en MySQL respecto a otras bases de datos. Debemos tratar el caso en el que se insertan o actualizan muchos registros en una tabla no transaccional en la que los cambios no pueden deshacerse cuando ocurre un error.

La filosofía básica es que MySQL Server trata de producir un error para cualquier cosa que detecte mientras parsea un comando que va a ejecutarse, y trata de recuperarse de cualquier error que ocurra mientras se ejecuta el comando. Lo hacemos en la mayoría de casos, pero todavía no en todos.

Las opciones en MySQL cuando ocurre un error son parar el comando en medio de la ejecución o recuperarse lo mejor posible del problema y continuar. Por defecto, el servidor utiliza esta última opción. Esto significa, por ejemplo, que el servidor puede cambiar algunos valores ilegales por el valor legal más próximo.

A partir de la versión 5.0.2 de MySQL, hay disponibles varios modos SQL para proporcionar un mayor control sobre cómo aceptar valores incorrectos y si continuar ejecutando el comando o abortarlo cuando ocurre el error. Usando estas opciones, puede configurar MySQL Server para actuar en un modo más tradicional como otros servidores de bases de datos que rechazan datos incorrectos. Los modos SQL pueden cambiarse en tiempo de ejecución, lo que permite a los clientes individuales seleccionar el comportamiento más apropiado para sus requerimientos. Consulte Sección 5.3.2, “El modo SQL del servidor”.

La siguiente sección describe qué ocurre para diferentes tipos de restricciones.

#### 1.7.6.1. Restricciones (constraints) en los índices `PRIMARY KEY` y `UNIQUE`

Normalmente, un error ocurre cuando trata de ejecutar un `INSERT` o `UPDATE` en un registro que viole la clave primaria, clave única o clave foránea. Si usa un motor transaccional como `InnoDB`, MySQL automáticamente deshace el comando. Si usa un motor no transaccional, MySQL para de procesar el comando en el registro en el que ocurre el error y deja sin procesar el resto de registros.

Si desea ignorar este tipo de violaciones de claves, MySQL permite la palabra clave `IGNORE` para `INSERT` y `UPDATE`. En este caso, MySQL ignora cualquier violación de clave y continúa procesando el siguiente registro. Consulte Sección 13.2.4, “Sintaxis de `INSERT`”. See Sección 13.2.10, “Sintaxis de `UPDATE`”.

Puede obtener información acerca del número de registro insertados o actualizados realmente con la función de la API de C `mysql_info()`. Consulte Sección 24.3.3.32, “`mysql_info()`”. A partir de MySQL 4.1 puede usar el comando `SHOW WARNINGS`. Consulte Sección 13.5.4.22, “Sintaxis de `SHOW WARNINGS`”.

De momento, sólo las tablas `InnoDB` soportan claves foráneas. Consulte Sección 15.6.4, “Restricciones (constraints) `FOREIGN KEY`”. El soporte para claves foráneas para tablas `MyISAM` está previsto para implementarse en MySQL 5.1.

#### 1.7.6.2. Restricciones (constraints) sobre datos inválidos

Antes de la versión 5.0.2 de MySQL, se permitía insertar valores ilegales convirtiéndolos en valores legales. A partir de la versión 5.0.2, sigue este compartimiento por defecto, pero puede elegir un tratamiento para valores incorrectos más tradicional, como no aceptarlos y abortar los comandos que los incluyen. Esta sección describe el comportamiento por defecto de MySQL (permisivo), así como el nuevo modo estricto SQL y en qué se diferencian.

Lo siguiente es cierto si no usa modo estricto. Si inserta un valor "incorrecto" en una columna, como `NULL` en una columna `NOT NULL` o una valor numérico demasiado grande en una columna numérica, MySQL cambia el valor al "mejor valor posible" para la columna en lugar de producir un error:

- Si trata de almacenar un valor fuera de rango en una columna numérica, MySQL Server en su lugar almacena cero, el menor valor posible, o el mayor valor posible en la columna.

- Para cadenas de carácteres, MySQL almacena una cadena vacía o tanto de la cadena de carácteras como quepa en la columna.

- Si trata de almacenar una cadena de carácteres que no empiece con un número en una columna numérica, MySQL Server almacena 0.

- MySQL le permite almacenar ciertos valores incorrectos en columnas `DATE` y `DATETIME` (tales como `'2000-02-31'` o `'2000-02-00'`). La idea es que no es el trabajo del servidor SQL validar fechas. Si MySQL puede almacenar una fecha y recuperarla fielmente, se almacena tal y como se da. Si la fecha es totalmente incorrecta (más allá de la capacidad del servidor para almacenarla), se almacena en su lugar el valor especial `'0000-00-00'`.

- Si intenta almacenar `NULL` en una columna que no admita valores `NULL` ocurre un error para los comandos `INSERT` de un solo registro. Para comandos `INSERT` de varios registros o para comandos `INSERT INTO... SELECT` , MySQL Server almacena el valor implícito para el tipo de datos de la columna. En general, es `0` para tipos numéricos, cadena vacía (`""`) para tipos de cadenas de carácteres, y el valor "cero" para tipos de fecha y tiempo. Los valores implícitos por defecto se discuten en Sección 13.1.5, “Sintaxis de `CREATE TABLE`”.

- Si un comando `INSERT` no especifica un valor para una columna, MySQL inserta su valor por defecto si la columna especifica un valor mediante la cláusula `DEFAULT`. Si la definición no tiene tal cláusula `DEFAULT` clause, MySQL inserta el valor por defecto implícito para el tipo de datos de la columna.

La razón para las reglas anteriores es que no podemos validar esas condiciones hasta que los comandos han empezado a ejecutarse. No podemos deshacer si encontramos un problema tras actualizar algunos registros, ya que el motor de almacenamiento puede no soportar rollback. La opción de terminar el comando no es siempre positiva; en este caso, la actualización quedaría "a medias", lo que posiblemente es la peor opción. En este caso, lo mejor es hacerlo "lo mejor posible" y continuar como si nada hubiera ocurrido.

A partir de MySQL 5.0.2, puede seleccionar un tratamiento de validación de datos de entrada más estricto usando los modos SQL `STRICT_TRANS_TABLES` o `STRICT_ALL_TABLES`. Consulte Sección 5.3.2, “El modo SQL del servidor”.

`STRICT_TRANS_TABLES` funciona así:

- Para motores de almacenamiento transaccionales, valores incorrectos en cualquier parte del comando provocan que se aborte el comando y se deshaga el mismo.

- Para motores no transaccionales, el comando aborta si ocurre un error en el primer registro a insertar o actualizar. (En este caso, el comando dejará la tabla intacta, igual que en una tabla transaccional.) Los errores en registros después del primero no abortan el comando. En lugar de ello, los valores incorrectos se ajustan y se generan advertencias en lugar de errores. En otras palabras, con `STRICT_TRANS_TABLES`, un valor incorrecto provoca que MySQL deshaga todas las actualizaciones hechas hasta el momento, si es posible.

Para chequeo estricto, active `STRICT_ALL_TABLES`. Es equivalente a `STRICT_TRANS_TABLES` excepto que en motores de almacenamiento no transaccionales, los errores abortan el comando incluso cuando hay datos incorrectos a partir del primer registro. Esto significa que si ocurre un error a medias de una inserción o actualización de varios registros en una tabla no transaccional, se produce una actualización parcial. Los primeros registros se insertan o actualizan, pero aquéllos a partir del punto en que ocurre el error no. Para evitar esto en tablas no transaccionales, use inserciones de un solo registro o use `STRICT_TRANS_TABLES` para obtener advertencias en lugar de errores. Para evitar problemas, no utilice MySQL para validar contenido de columnas. Es preferible (y a menudo más rápido) dejar que la aplicación se asegure de pasar sólo valores legales a la base de datos.

Con cualquiera de las opciones de modo estricto, puede hacer que se traten los errores como advertencias usando `INSERT IGNORE` o `UPDATE IGNORE` en lugar de `INSERT` o `UPDATE` sin `IGNORE`.

#### 1.7.6.3. Restricciones `ENUM` y `SET`

Las columnas `ENUM` y `SET` proporcionan una manera eficiente de definir columnas que contienen un conjunto dado de valores. Sin embargo, antes de MySQL 5.0.2, `ENUM` y `SET` no son restricciones reales. Esto es por la misma razón que `NOT NULL` tampoco lo es. Consulte Sección 1.7.6.2, “Restricciones (constraints) sobre datos inválidos”.

Las columnas de tipo `ENUM` siempre tienen un valor por defecto. Si no especifica un valor por defecto, entonces será `NULL` para las columnas que permitan valores `NULL`, si no, se utiliza el primer valor de la enumeración como valor por defecto.

Si inserta un valor incorrecto en una columna `ENUM` o si fuerza insertar un valor en una columna `ENUM` con `IGNORE`, se inicializa al valor reservado para enumeraciones `0`, el cual se muestra como una cadena vacía en un contexto de cadenas de carácteres. Consulte Sección 11.4.4, “El tipo de columna `ENUM`”.

Si insertar un valor incorrecto en una columna `SET`, se ignora el valor incorrecto. Por ejemplo, si la columna puede contener los valores `'a'`, `'b'`, y `'c'`, un intento de insertar `'a,x,b,y'` resulta en un valor de `'a,b'`. Consulte Sección 11.4.5, “El tipo `SET`”.

En MySQL 5.0.2, puede configurar el servidor para que use el modo estricto de SQL. Consulte Sección 5.3.2, “El modo SQL del servidor”. Cuando el modo estricto está activado, la definición de columnas `ENUM` o `SET` no actúa como una restricción en valores insertados en la columna. Los valores que no satisfacen estas condiciones provocan un error:

- Un valor `ENUM` debe elegirse entre los listados en la definición de la columna, o el equivalente numérico interno. El valor no puede ser un valor de error (esto es 0 o la cadena vacía). Para una columna definida como `ENUM('a','b','c')`, valores tales como `""`, `'d'`, y `'ax'` son ilegales y rehusados.

- Un valor `SET` debe ser una cadena vacía o un valor consistente en uno o más valores listados en la definición de la columna separados por comas. Para una columna definida como `SET('a','b','c')`, valores tales como `'d'`, y `'a,b,c,d'` serían ilegales y, por lo tanto, rehusados.

Se pueden suprimir los errores derivados de valores inválidos en modo estricto usando `INSERT IGNORE` o `UPDATE IGNORE`. En ese caso, se genera una advertencia en lugar de un error. Para tipos `ENUM`, el valor se inserta como un miembro erróneo (`0`). Para tipo `SET`, el valor se inserta igual excepto que se borra cualquier subcadena inválida. Por ejemplo, `'a,x,b,y'` se convertiría en `'a,b'`, como se ha descrito.

Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.

Anterior |  | Siguiente
Prefacio | Inicio | Capítulo 2. Instalar MySQL