Tabla de contenidos
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>
.
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.
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> SELECTcol_name
FROMdb_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:
RESETreset_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> setenvVARNAME
value
shell>some_command
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.
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.
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.
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.
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.
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
”.
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.
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 |
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. |
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”.
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.
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.
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.
Lista de correo Española. Envíe un correo a
subscribe mysql your@email.address
para
subscribirse a la lista.
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.
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
para cada
tabla implicada. Mientras más información tengamos
acerca de la situación, es más posible que podamos
ayudar..
tbl_name
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.
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
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/).
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
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.
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.
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”.
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';
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
”.
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.
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.
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
”.
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?
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.
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.
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:
Use LOCK TABLES
para bloquear todas
las tablas a las que quiere acceder.
Compruebe las condiciones que deben darse antes de ejecutar la actualización.
Actualice si todo es correcto.
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;
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).
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.
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".
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
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.
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.
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
.
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.