Manual teórico de SQL en MySQL / MariaDB

1. Primeros pasos: la consola de MySQL

1.1. Dos programas distintos: mysql y mysqldump

Error muy común: escribir mysqldump ... dentro de la consola MariaDB [(none)]>. Allí no existe y produce un error de sintaxis. Primero sal con exit.

1.2. Iniciar sesión en la base de datos desde la consola

Hay dos formas. Ambas requieren que MySQL esté iniciado (botón Start de MySQL en el panel de XAMPP).

Opción A: desde CMD, entrando a la carpeta de MySQL

1. Abre CMD: tecla Windows, escribe cmd y presiona Enter.
2. Ve a la carpeta donde están los programas de MySQL y conéctate:

• -u root: el usuario con el que entras (en XAMPP el administrador se llama root).
• -p: pide la contraseña de forma oculta. En un XAMPP recién instalado root no tiene contraseña: presiona Enter sin escribir nada (o conéctate directamente con mysql -u root).
• No escribas la contraseña pegada en el comando (-pMiClave): queda visible en pantalla y en el historial de la consola.

Si la conexión es correcta verás algo así:

(none) indica que todavía no has elegido una base de datos.

Opción B: con el botón «Shell» del panel de XAMPP

En el panel de control de XAMPP, el botón Shell abre una consola que ya tiene configurada la ruta de MySQL (agrega C:\xampp\mysql\bin a la variable PATH). Por eso puedes conectarte sin cambiar de carpeta:

Errores frecuentes al conectarse

1.3. Comandos básicos dentro de la consola

• Toda sentencia termina en ;. Si presionas Enter sin él, aparece -> esperando el resto: escribe ; y Enter.
• Si te equivocas a mitad de una sentencia, escribe \c para cancelarla.
• Terminar una consulta con \G en lugar de ; muestra cada fila en vertical (útil con tablas anchas).
• En DESCRIBE, PRI = clave primaria y MUL = columna con índice que admite repetidos (como una clave foránea).

2. DDL: definir la estructura (CREATE, ALTER, DROP)

2.1. Las familias de sentencias SQL

2.2. Bases de datos: crear, ver, usar y eliminar

• CHARACTER SET utf8mb4 permite guardar tildes, eñes y emojis. Inclúyelo siempre al crear una base.
• IF NOT EXISTS evita el error si ya existe (solo deja una advertencia). Es útil en scripts que se ejecutan varias veces.
• Para eliminar una base y todo su contenido: DROP DATABASE colegio; (no pide confirmación ni se puede deshacer).

2.3. Crear tablas: CREATE TABLE

Tipos de datos más usados

Restricciones (reglas que protegen los datos)

CONSTRAINT nombre le da un nombre a la regla (útil para luego borrarla o entender un error). UNIQUE (aprendiz_id, curso_id) es una restricción de tabla: la combinación no se repite (un aprendiz no se inscribe dos veces al mismo curso). Las llaves foráneas y sus opciones ON DELETE se explican en la sección 2.6.

Revisar lo creado

SHOW CREATE TABLE muestra la sentencia completa tal como la guardó el servidor: observa que BOOLEAN se convirtió en tinyint(1) y TRUE en 1. El \G final muestra el resultado en vertical.

Errores y comprobaciones al crear

El CHECK rechazó 15 créditos porque la regla exige entre 1 y 10. Ojo: con IF NOT EXISTS la tabla existente no se modifica; si necesitas otra estructura, usa ALTER TABLE.

2.4. Modificar tablas: ALTER TABLE

• MODIFY cambia el tipo conservando el nombre; CHANGE pide el nombre viejo, el nuevo y el tipo completo (aunque no cambie).
• Con MODIFY y CHANGE hay que repetir todas las restricciones de la columna (NOT NULL, DEFAULT…): las que no escribas se pierden.

RENAME COLUMN existe en MySQL 8 y MariaDB 10.5 o superior, pero no en el MariaDB 10.4 de XAMPP: allí se usa CHANGE COLUMN.

El nombre completo se perdió para siempre. Antes de cambiar tipos o tamaños en una tabla con datos, haz una copia de seguridad (sección 11.1) y revisa los datos más largos con SELECT MAX(CHAR_LENGTH(nombre)) FROM aprendices;.

2.5. Índices: búsquedas más rápidas

Un índice es como el índice de un libro: permite encontrar filas sin recorrer toda la tabla. Las claves primarias y las columnas UNIQUE ya tienen uno.

Non_unique = 0 indica índice único. Crea índices en columnas que se usan mucho en WHERE, JOIN u ORDER BY; no en todas: cada índice hace más lentos los INSERT y UPDATE. Para comprobar si una consulta realmente usa un índice se usa EXPLAIN (4.17).

2.6. Llaves foráneas (FOREIGN KEY): relacionar tablas

Una llave foránea es una regla que obliga a que el valor de una columna exista en otra tabla. La tabla que guarda la referencia es la hija (ciudades.departamento_id) y la tabla referenciada es la padre (departamentos.id). Así la base de datos impide, por sí misma, datos "huérfanos" o inconsistentes.

Sintaxis completa

• Se puede escribir dentro del CREATE TABLE (como restricción de tabla) o agregarse después con ALTER TABLE ... ADD CONSTRAINT.
• CONSTRAINT nombre es opcional pero muy recomendado: sin nombre, MySQL inventa uno (sedes_ibfk_1) y es más difícil identificarla en los errores o borrarla.
• Convención útil: fk_hija_padre, por ejemplo fk_ciudad_depto.

Crear tablas relacionadas: el padre primero

El error 1005 con errno 150 es genérico ("la llave foránea está mal formada"). La causa real siempre aparece en SHOW WARNINGS: aquí, la tabla padre departamentos todavía no existe. Se crea primero el padre y luego la hija:

Sin nombre y con índice automático

• Como no se le dio nombre, MySQL la llamó sedes_ibfk_1 (InnoDB foreign key número 1).
• MySQL creó solo un índice (KEY `ciudad_id`) en la columna hija: la llave foránea lo necesita para verificar rápido.

Requisitos: cuándo NO se puede crear

Los tres errores son idénticos: solo SHOW WARNINGS; dice cuál requisito falló (columna derecha de la tabla de arriba).

No dio error, aceptó la ciudad 999 (que no existe) y en la estructura no hay ningún CONSTRAINT: solo quedó un índice. Usa siempre InnoDB, que es el motor predeterminado (no escribas ENGINE=MyISAM).

Agregar una llave foránea a una tabla que ya tiene datos

No se puede crear porque ya hay un dato que la viola: un cliente con la ciudad 7, que no existe (el nombre raro #sql-... es la copia temporal que MySQL usa durante el ALTER). Primero se buscan los huérfanos con un LEFT JOIN:

Un NULL en la columna hija sí está permitido: significa "sin ciudad" y no viola la llave foránea (Pedro no causó el error).

Opciones ON DELETE y ON UPDATE

Definen qué pasa con las filas hijas cuando se borra (ON DELETE) o se cambia el id (ON UPDATE) de su fila padre:

Luis quedó sin ciudad (SET NULL) y Ana pasó automáticamente a la ciudad 10 (CASCADE). Con RESTRICT, en cambio:

El efecto sobre los datos al usar INSERT, UPDATE y DELETE se profundiza en las secciones 3.2, 3.3 y 3.4.

Ver las llaves foráneas de una base

Además de SHOW CREATE TABLE tabla\G, el catálogo information_schema las lista todas:

La segunda consulta muestra las reglas de cada llave: las que no indicaron opciones quedaron en RESTRICT.

Modificar o eliminar una llave foránea

No existe un "ALTER CONSTRAINT": para cambiar una llave foránea (por ejemplo, sus opciones) se elimina y se vuelve a crear:

• DROP FOREIGN KEY elimina la regla, pero el índice queda. Si ya no se necesita: ALTER TABLE ciudades DROP INDEX fk_ciudad_depto;
• Para borrarla hay que conocer su nombre exacto (por eso conviene nombrarlas): búscalo con SHOW CREATE TABLE o en information_schema.

Casos especiales

En la autorreferencia, el primer registro (la jefa principal) se inserta con jefe_id en NULL; por eso la columna debe permitir NULL.

Orden correcto al crear y al borrar tablas relacionadas

2.7. Renombrar y eliminar: RENAME y DROP

• DROP TABLE elimina la tabla con su estructura y todos sus datos.
• No se puede eliminar una tabla de la que dependen otras por llave foránea (cursos es usada por matriculas): primero se elimina la tabla dependiente o su llave foránea.
• DROP DATABASE colegio; elimina la base entera: Query OK, 4 rows affected indica cuántos objetos borró.

2.8. Vistas: consultas guardadas con nombre

Una vista no guarda datos: cada vez que se consulta, ejecuta su SELECT. Sirve para simplificar consultas largas o mostrar solo algunas columnas.

2.9. Otras formas de crear tablas y columnas

Columnas calculadas (generadas)

Una columna generada calcula su valor a partir de otras columnas de la misma fila, y se mantiene sola al cambiar los datos:

• El total del Té se recalculó solo al cambiar la cantidad (2 → 10). El valor 99 que se intentó escribir en total fue ignorado.
• STORED guarda el resultado en disco (se puede indexar); VIRTUAL lo calcula cada vez que se consulta (no ocupa espacio).

Copiar la estructura o crear desde una consulta

CREATE TABLE ... AS SELECT copia las columnas y los datos, pero no copia la clave primaria, los índices ni las llaves foráneas (y la columna calculada pasó a ser una columna normal). Útil para respaldos rápidos de una tabla o tablas de reporte.

Tablas temporales

Una tabla TEMPORARY solo existe para tu conexión (otros usuarios no la ven) y se borra sola al cerrar la consola. Observa que no aparece en SHOW TABLES, aunque se puede consultar. Sirve para guardar resultados intermedios.

Reiniciar o adelantar el contador AUTO_INCREMENT

No se puede bajar el contador por debajo del id más alto que ya existe: MySQL lo ajusta solo al siguiente número libre. Para volver a 1 hay que vaciar la tabla con TRUNCATE (3.4).

2.10. Las sentencias DDL no se pueden deshacer

CREATE, ALTER, DROP, RENAME y TRUNCATE hacen un COMMIT automático: el ROLLBACK no los revierte (y además confirma lo que hubiera pendiente en la transacción). La única protección real ante un DROP o un ALTER equivocado es una copia de seguridad.

2.11. Chuleta

3. DML: manipular los datos

El DML (Data Manipulation Language) agrupa las sentencias que trabajan con los datos de las tablas ya creadas: INSERT (agregar), UPDATE (modificar) y DELETE (eliminar). A diferencia del DDL, sus cambios sí se pueden deshacer dentro de una transacción.

• 3.1 Insertar (una tabla)
• 3.2 Insertar (tablas relacionadas)
• 3.3 UPDATE
• 3.4 DELETE y TRUNCATE

4. Consultas SQL: SELECT y JOIN

Una consulta le pide datos a la base de datos sin modificarlos. Siempre empieza con SELECT y su resultado es una tabla temporal (filas y columnas) que se muestra y luego desaparece. En este módulo aprenderás a filtrar, calcular, resumir y combinar información de una o varias tablas.

4.1. Anatomía de una consulta y orden de ejecución

Las cláusulas se escriben en ese orden, pero MySQL las ejecuta en este otro:

1. FROM / JOIN
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. ORDER BY
7. LIMIT

Esto explica dos reglas que confunden al principio: WHERE no puede usar funciones de agregado (todavía no existen los grupos) y ORDER BY sí puede usar los alias definidos en el SELECT (ya se calcularon). Solo SELECT y FROM son obligatorias; las demás se usan cuando se necesitan.

4.2. SELECT: elegir columnas, alias y cálculos

Elige las columnas separadas por comas, en el orden en que quieres verlas. SELECT * trae todas, pero en los ejercicios debes mostrar exactamente las columnas pedidas.

Con AS renombras una columna en el resultado. También puedes calcular con + - * /.

4.3. ORDER BY, LIMIT y OFFSET

ASC (por defecto) ordena de menor a mayor; DESC de mayor a menor.

Con varias columnas, la segunda desempata a la primera: primero por especie y, dentro de cada especie, por nombre.

LIMIT n devuelve solo las primeras n filas. Úsalo SIEMPRE después de ORDER BY para que "los primeros" tengan sentido (aquí: las 3 mascotas más pesadas).

OFFSET n salta las primeras n filas: es la base de la paginación (página 2 de 3 en 3). También se escribe LIMIT 3, 3 (desde, cuántas).

Al ordenar de forma ascendente, los NULL salen primero (Luna no tiene raza). Con DESC salen al final.

4.4. WHERE: filtrar filas

Perros que sean muy jóvenes o muy viejos. Sin los paréntesis, la condición cambiaría de significado.

Las fechas se escriben como texto 'AAAA-MM-DD'.

'%o%': contiene una "o" en cualquier posición.

'_o%': la segunda letra es "o" (el _ ocupa exactamente un carácter).

NULL significa "sin valor". Se pregunta con IS NULL…

…y NUNCA con = NULL: cualquier comparación con NULL da "desconocido", por eso esta consulta no devuelve nada.

4.5. DISTINCT: quitar repetidos

Hay 7 mascotas, pero solo 3 especies distintas.

4.6. Funciones de fila (se aplican a cada fila)

ROUND redondea al más cercano; FLOOR siempre hacia abajo.

DATEDIFF(fin, inicio) devuelve la diferencia en días (ojo con el orden de los argumentos).

TIMESTAMPDIFF(MONTH | YEAR | DAY, inicio, fin) cuenta unidades completas: ideal para calcular edades o antigüedad.

4.7. Manejo de NULL y funciones condicionales

NULL significa "valor desconocido o ausente". Casi cualquier operación con NULL da NULL, así que hay funciones específicas para tratarlo y para elegir valores según una condición:

COALESCE reemplaza los NULL por un valor legible.

IFNULL hace lo mismo con dos valores. Úsalo cuando solo hay un posible reemplazo.

CASE "buscado": evalúa las condiciones en orden y usa la primera que se cumpla. Por eso la condición más exigente va primero.

CASE "simple": compara una sola columna con valores fijos. Es más corto cuando todas las condiciones son igualdades.

IF sirve cuando solo hay dos opciones.

NULLIF(motivo, 'Control') vuelve NULL las citas de control, y COUNT(columna) no cuenta los NULL: así se cuentan solo las que no son control.

Uso clásico de NULLIF: evitar dividir por cero. Para Luna (edad 1) el divisor sería 0; NULLIF(edad - 1, 0) lo convierte en NULL y el resultado es NULL en lugar de un error (en modo estricto) o una advertencia.

GREATEST fija un valor mínimo (nunca menos de 40.000) y LEAST un tope (nunca más de 100.000), fila por fila.

Jorge no tiene teléfono: CONCAT con un NULL devuelve todo NULL, mientras que CONCAT_WS simplemente lo salta.

Las trampas de NULL en una sola consulta

NULL = NULL no es verdadero sino NULL (desconocido); <=> e IS NULL sí responden 1. Un solo NULL vuelve NULL a GREATEST y hace que NOT IN (…, NULL) nunca sea verdadero: un NOT IN con un NULL en la lista no devuelve ninguna fila.

4.8. Funciones de agregado (resumen muchas filas en una)

Hay 7 mascotas, pero solo 6 tienen raza registrada (Luna tiene NULL).

Usa ROUND(AVG(...), 2) cuando el enunciado pida 2 decimales.

Primero WHERE filtra las filas y luego se agrega solo lo que quedó.

4.9. GROUP BY y HAVING

GROUP BY parte las filas en grupos (uno por cada valor distinto) y aplica las funciones de agregado a cada grupo. Regla de oro: toda columna del SELECT que no esté dentro de una función de agregado debe aparecer en el GROUP BY.

Una fila por especie, con su cantidad y su peso promedio.

También se puede agrupar por un cálculo, por ejemplo el mes de una fecha.

Solo las especies con 2 o más mascotas (el Ave queda fuera).

Ambos a la vez: WHERE descarta las citas costosas y HAVING descarta los motivos que aparecen una sola vez.

4.10. JOIN: combinar dos tablas relacionadas

Las tablas se relacionan con claves foráneas: mascotas.dueno_id guarda el id de un dueño. Un JOIN junta cada fila de una tabla con las filas de la otra que cumplan la condición ON. Usa alias cortos (mascotas m) y antepón el alias a cada columna (m.nombre) para evitar ambigüedades.

INNER JOIN

Toby no aparece porque no tiene dueño (no hay pareja).

Después de unir, WHERE puede filtrar por columnas de cualquiera de las tablas.

LEFT JOIN

Todas las mascotas aparecen; las que no tienen citas muestran NULL en la fecha.

Patrón "sin relación": LEFT JOIN + WHERE derecha.id IS NULL encuentra las mascotas que nunca han tenido cita.

RIGHT JOIN

Conserva todos los dueños (la tabla de la derecha), incluso Andrés, que no tiene mascotas. Un RIGHT JOIN equivale a un LEFT JOIN con las tablas invertidas.

4.11. Varias tablas, agregados y auto-JOIN

Se encadenan los JOIN: dueños → mascotas → citas. Cada JOIN lleva su propia condición ON.

JOIN + GROUP BY: cuánto ha gastado cada dueño. Agrupa por d.id, d.nombre por si hay dos personas con el mismo nombre.

Auto-JOIN: con dos alias de la misma tabla se comparan filas entre sí (pares de mascotas del mismo dueño). a.id < b.id evita repetir pares e impide emparejar una mascota consigo misma.

4.12. Trampas frecuentes (con prueba)

• Usar = NULL en vez de IS NULL: nunca encuentra nada.
• Poner una función de agregado en WHERE (WHERE COUNT(*) > 2): es un error; va en HAVING.
• Mostrar una columna que no está en el GROUP BY ni dentro de un agregado: el valor es arbitrario o da error.
• Olvidar el desempate en ORDER BY cuando el enunciado lo pide ("en empate, por nombre").
• Un NULL dentro de un NOT IN hace que la condición nunca se cumpla (ver 4.7).
• Comillas: los textos y fechas van entre comillas simples ('Cali'), los números sin comillas.

4.13. GROUP_CONCAT y WITH ROLLUP

GROUP_CONCAT junta en un solo texto los valores de cada grupo (con su propio ORDER BY y separador).

WITH ROLLUP agrega una fila final de total general (la que tiene NULL en la columna agrupada).

4.14. CROSS JOIN, FULL OUTER JOIN y UNION

CROSS JOIN combina todas las filas con todas, a propósito (aquí, el dueño de Cali con cada mascota). Útil para generar combinaciones.

UNION ALL apila resultados de varias consultas (mismo número de columnas). UNION sin ALL además quita filas repetidas.

MySQL/MariaDB no tiene FULL OUTER JOIN: se simula uniendo un LEFT y un RIGHT JOIN. Aparecen tanto Andrés (sin mascotas) como Toby (sin dueño).

4.15. Subconsultas y EXISTS

Una subconsulta es un SELECT dentro de otro. Puede ir en el WHERE, en el FROM o en el SELECT.

Subconsulta que devuelve un valor: mascotas más pesadas que el promedio.

Subconsulta que devuelve una lista para usar con IN: dueños que tienen gatos.

NOT EXISTS: mascotas para las que no existe ninguna cita (mismo resultado que el patrón LEFT JOIN … IS NULL de 4.10).

Subconsulta en el FROM (tabla derivada): se le da un alias y se consulta como si fuera una tabla.

4.16. CTE (WITH) y funciones de ventana

Una CTE (WITH nombre AS (…)) da nombre a una subconsulta y la deja al inicio: la misma consulta de 4.15, más fácil de leer.

Una CTE recursiva genera filas que no existen en ninguna tabla (los meses 1 a 6). Con LEFT JOIN aparecen también los meses sin citas (5 y 6).

Las funciones de ventana (OVER) calculan sobre un grupo de filas sin juntarlas en una: aquí, el puesto de cada mascota por peso dentro de su especie.

SUM(…) OVER (ORDER BY fecha) calcula un acumulado fila por fila.

4.17. EXPLAIN: ¿usa mi consulta un índice?

EXPLAIN antes de una consulta no la ejecuta: muestra el plan que seguirá el servidor para resolverla, es decir, qué tablas lee, en qué orden, si usa un índice (2.5) y cuántas filas calcula que tendrá que revisar. Es la forma de comprobar si un índice sirve. Ejemplo con una tabla pedidos de 50.000 filas:

type = ALL y key = NULL: recorre toda la tabla (unas 49.071 filas estimadas) para encontrar los 25 pedidos del cliente. Después de crear un índice:

Ahora usa el índice (key) y lee solo 25 filas en lugar de casi 50.000.

Trampa frecuente: envolver la columna en una función impide usar el índice. Con un índice en fecha:

• Las dos consultas devuelven lo mismo, pero solo la segunda aprovecha el índice: compara la columna sola contra un rango.
• Lo mismo pasa con LIKE '%texto' (comodín al inicio): no puede usar el índice. LIKE 'texto%' sí.
• En un JOIN, EXPLAIN muestra una fila por tabla. La columna de la llave foránea debería tener índice (type = ref en la tabla hija); si aparece ALL en una tabla grande, falta un índice.
• En tablas pequeñas (unas cientas de filas) el servidor puede preferir leer toda la tabla aunque exista un índice: es normal.

4.18. Cómo responder en la plataforma

• Escribe una sola consulta que empiece con SELECT. No se permiten subconsultas (un SELECT dentro de otro) ni UNION.
• Muestra exactamente las columnas pedidas y en ese orden. Los nombres o alias de las columnas no importan.
• Si el enunciado pide un orden, debes escribir ORDER BY y el orden de las filas se evalúa; si no lo pide, el orden no importa. Aunque a veces las filas salgan ordenadas sin él (por ejemplo, después de un GROUP BY), la base de datos no lo garantiza, así que sin ORDER BY la respuesta no se acepta.
• Si el enunciado pide redondear, usa ROUND(valor, 2).
• Tu consulta se prueba con los datos que ves y con otros datos ocultos: si escribes valores fijos (por ejemplo, WHERE id IN (2, 5) en vez de la condición real), no aprobará.
• Algunos retos exigen una palabra clave (por ejemplo LEFT JOIN, HAVING o COALESCE): aparece indicada en el reto.
• Si fallas, verás cuántas filas y columnas devolvió tu consulta y una vista previa de tu resultado para comparar con lo pedido.

4.19. Chuleta: cómo armar una consulta paso a paso

1. ¿De qué tablas salen los datos? → FROM y, si son varias, JOIN ... ON por sus claves.
2. ¿Deben aparecer también los que no tienen relación? → LEFT/RIGHT JOIN. ¿Solo los que no la tienen? → LEFT JOIN ... WHERE derecha.id IS NULL.
3. ¿Qué filas sirven? → WHERE.
4. ¿Pide "por cada…", "cuántos por…", "total por…"? → GROUP BY + función de agregado.
5. ¿Pide "solo los que tengan más de…" sobre un total? → HAVING.
6. ¿Hay valores vacíos que mostrar de otra forma? → COALESCE / IFNULL.
7. ¿Qué columnas y en qué orden? → SELECT.
8. ¿Pide un orden o "los N primeros"? → ORDER BY (+ desempate) y LIMIT.

5. Transacciones: todo o nada

Una transacción es un grupo de sentencias que la base de datos trata como una sola unidad: o se guardan todas, o no se guarda ninguna. Sus sentencias forman la familia TCL (Transaction Control Language): START TRANSACTION, COMMIT, ROLLBACK y SAVEPOINT.

5.1. ¿Qué es una transacción?

Piensa en una transferencia bancaria de 100.000 de Ana a Luis. Son dos sentencias: restar a Ana y sumar a Luis. Si el servidor se apaga justo después de la primera, el dinero desaparece: a Ana se le restó y a Luis nunca se le sumó. Una transacción evita ese estado intermedio: hasta que no se confirma, ningún cambio es definitivo y, si algo falla, todos se deshacen.

5.2. START TRANSACTION, COMMIT y ROLLBACK

La transferencia completa, confirmada con COMMIT:

Un error grave (un UPDATE sin WHERE) deshecho con ROLLBACK:

• Mientras la transacción está abierta, tú ves tus cambios pendientes; los demás usuarios todavía no (5.11).
• Si cierras la consola o se pierde la conexión sin COMMIT, la transacción se deshace sola.
• BEGIN; es un sinónimo de START TRANSACTION; en la consola (dentro de un procedimiento usa START TRANSACTION, porque allí BEGIN abre un bloque).
• En el módulo de DML verás este mismo recurso aplicado: revisar un UPDATE (3.3) o un DELETE (3.4) antes de confirmarlo, y guardar un pedido con sus líneas (3.2).

5.3. autocommit: cada sentencia es su propia transacción

Por defecto autocommit está activado (1): cada sentencia que no está dentro de un START TRANSACTION se confirma sola e inmediatamente. Por eso un UPDATE escrito "suelto" ya no se puede deshacer.

Si se desactiva en la sesión, todas las sentencias quedan pendientes hasta un COMMIT o un ROLLBACK:

La forma recomendada es dejar autocommit = 1 y abrir una transacción con START TRANSACTION solo cuando se necesita: así queda claro dónde empieza y dónde termina.

5.4. Propiedades ACID

Una base de datos transaccional garantiza cuatro propiedades, conocidas por sus iniciales en inglés:

5.5. Puntos de guardado: SAVEPOINT

Un SAVEPOINT marca un punto dentro de la transacción. ROLLBACK TO nombre deshace solo lo que se hizo después de ese punto; lo anterior sigue pendiente y se puede confirmar.

• Puede haber varios savepoints con nombres distintos; RELEASE SAVEPOINT nombre elimina uno sin deshacer nada.
• Un ROLLBACK sin TO sigue deshaciendo toda la transacción.

5.6. Lo que una transacción no puede deshacer

• Sentencias DDL (CREATE, ALTER, DROP, RENAME, TRUNCATE): hacen un COMMIT automático antes y después de ejecutarse. Además de no poder deshacerse, confirman lo que estuviera pendiente. Ver el ejemplo en 2.10.
• Tablas que no son InnoDB. Solo el motor InnoDB (el predeterminado) maneja transacciones. En una tabla MyISAM, el ROLLBACK no la toca y avisa con una advertencia:

Para saber el motor de cada tabla: SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'banco';. Tampoco se deshacen los valores AUTO_INCREMENT ya usados: el siguiente id salta el número "gastado" (3.1).

5.7. Transacciones en procedimientos, funciones y triggers

5.8. Dos usuarios a la vez: bloqueos de fila

Cuando una transacción modifica una fila, InnoDB la bloquea hasta el COMMIT o el ROLLBACK. Si otra sesión quiere modificar la misma fila, espera. Las demás filas siguen libres: el bloqueo es por fila, no por tabla. En el ejemplo, la sesión A empieza primero y la B un segundo después (dos consolas abiertas a la vez):

B tardó 2.940 s: estuvo esperando a que A confirmara. Ningún cambio se perdió (350.000 − 10.000 + 20.000 = 360.000). Si la espera supera innodb_lock_wait_timeout (50 segundos por defecto), la sentencia de B se cancela:

Por eso una transacción debe ser corta: mientras está abierta, bloquea a los demás. Nunca dejes una transacción abierta mientras esperas a un usuario.

5.9. Leer para modificar: SELECT … FOR UPDATE

Un SELECT normal no bloquea. Si dos sesiones leen el mismo saldo, calculan el nuevo valor en la aplicación y lo guardan, la segunda escritura borra la primera: se produce una actualización perdida. SELECT ... FOR UPDATE lee la fila y la bloquea como si ya se fuera a modificar; la otra sesión espera y luego lee el valor actualizado:

B no leyó el saldo viejo (360.000) sino el ya descontado por A (300.000). Se usa siempre que se lee un valor para decidir con él (¿hay saldo suficiente?, ¿hay stock?) y luego modificarlo. LOCK IN SHARE MODE hace un bloqueo más débil: permite que otros lean, pero no que modifiquen.

5.10. Interbloqueos (deadlock)

Un interbloqueo ocurre cuando dos transacciones se esperan mutuamente: A tiene la fila 1 y quiere la 2; B tiene la 2 y quiere la 1. Ninguna puede seguir. InnoDB lo detecta de inmediato, cancela una de las dos (deshace toda su transacción) y deja continuar a la otra:

• A recibió el error 1213 y toda su transacción se deshizo, incluido su primer UPDATE. La aplicación debe volver a intentarla.
• Para evitarlos: accede a las filas siempre en el mismo orden (por ejemplo, de menor a mayor id) y mantén las transacciones cortas.

5.11. Niveles de aislamiento

El nivel de aislamiento decide qué cambios de otras transacciones puede ver la tuya mientras está abierta. Más aislamiento = menos sorpresas, pero más esperas. Cada nivel evita distintos problemas:

• Lectura sucia: leer un cambio que otra transacción todavía no confirma (y que quizá deshaga).
• Lectura no repetible: leer la misma fila dos veces en una transacción y obtener valores distintos porque otra la modificó y confirmó.
• Fila fantasma: repetir una consulta y que aparezcan filas nuevas que otra transacción insertó.

En los tres ejemplos, la sesión A lee un saldo, espera dos segundos y lo vuelve a leer; mientras tanto, la sesión B lo modifica.

Lo habitual es dejar el predeterminado (REPEATABLE READ) y usar SELECT ... FOR UPDATE (5.9) cuando se lee para modificar.

5.12. Buenas prácticas

• Transacciones cortas: abre, haz los cambios y confirma. Nunca esperes a que un usuario responda con la transacción abierta.
• Siempre termina con COMMIT o ROLLBACK; revisa los resultados (ROW_COUNT(), un SELECT) antes de confirmar.
• Usa SELECT ... FOR UPDATE cuando leas un valor para decidir con él y luego modificarlo.
• Accede a las filas en el mismo orden en todas las operaciones para evitar interbloqueos, y prepara la aplicación para reintentar ante un error 1213 o 1205.
• No mezcles DDL dentro de una transacción: confirma lo pendiente sin avisar (5.6).
• Usa tablas InnoDB; MyISAM no admite transacciones ni llaves foráneas.

5.13. Chuleta

6. Procedimientos almacenados

6.1. ¿Qué es un procedimiento y cuándo usarlo?

Un procedimiento almacenado es un programa con nombre guardado dentro de la base de datos. Agrupa varias instrucciones SQL (consultas, inserciones, condiciones, ciclos, transacciones) y se ejecuta explícitamente con CALL nombre(argumentos).

6.2. Sintaxis general

Un procedimiento puede no tener parámetros: CREATE PROCEDURE sp_x() ... y se llama con CALL sp_x();. Usa prefijos como p_ (parámetros) y v_ (variables) para no confundirlos con columnas.

¿Qué es DELIMITER y cuándo se usa?

En la consola de MariaDB/MySQL, en la pestaña SQL de phpMyAdmin o en Workbench, el punto y coma (;) indica dónde termina una sentencia: al verlo, el programa envía al servidor todo lo escrito hasta ahí. El problema es que dentro de BEGIN ... END hay varias instrucciones, y cada una termina en ;. El programa corta el CREATE PROCEDURE en el primer ; y lo envía incompleto:

DELIMITER cambia temporalmente el símbolo que marca el final de la sentencia. Así los ; del cuerpo dejan de cortarla, y el CREATE PROCEDURE completo se envía al llegar al nuevo símbolo:

• Es una orden del programa cliente, no de SQL: el servidor nunca recibe la palabra DELIMITER. Por eso no aparece en la definición que se guarda.
• El símbolo puede ser cualquiera que no aparezca dentro del cuerpo; los más usados son // y $$. Deja un espacio entre DELIMITER y el símbolo.
• Siempre restáuralo con DELIMITER ; al terminar. Si lo olvidas, las siguientes sentencias no se ejecutan hasta que escribas //.
• Solo hace falta cuando el cuerpo tiene varios ; (un bloque BEGIN ... END con varias instrucciones). Un cuerpo de una sola instrucción sin BEGIN ... END no lo necesita: CREATE PROCEDURE sp_contar() SELECT COUNT(*) FROM productos;
• Vale igual para funciones (7), triggers (8) y eventos (9): cada vez que el cuerpo lleve BEGIN ... END con varias instrucciones, se escriben entre DELIMITER // y DELIMITER ;.
• En phpMyAdmin, la pestaña SQL tiene un campo Delimitador debajo del editor: escribe ahí // y termina la sentencia con // (o usa DELIMITER en el texto, que phpMyAdmin también entiende).
• En esta plataforma no hace falta: cada respuesta se envía como una sola sentencia. Si escribes DELIMITER (como lo harías en la consola), la plataforma lo reconoce y lo quita antes de evaluar.

6.3. Parámetros de entrada (IN)

Un parámetro IN (el modo por defecto) recibe un valor desde el CALL. Si el procedimiento lo cambia, quien llama no ve el cambio.

6.4. Procedimientos que devuelven resultados

Un SELECT sin INTO dentro del procedimiento devuelve sus filas a quien lo llama, como si fuera una consulta:

6.5. Parámetros OUT e INOUT

Para asignar el resultado de una consulta a una variable o parámetro se usa SELECT ... INTO variable. Un SELECT sin INTO solo muestra un resultado (6.4): no guarda nada en el parámetro.

Parámetro OUT con SELECT ... INTO

Parámetro INOUT

6.6. Variables y control de flujo

• Variables locales: DECLARE v_total INT DEFAULT 0; y se asignan con SET v_total = v_total + 1;. Solo existen dentro del procedimiento.
• Variables de sesión (con @): SET @x = 5; viven mientras dure la conexión; se usan para recibir parámetros OUT.
• Condicionales: IF cond THEN ... ELSEIF cond THEN ... ELSE ... END IF; o CASE ... END CASE;
• Ciclos: WHILE cond DO ... END WHILE; (puede no ejecutarse nunca), REPEAT ... UNTIL cond END REPEAT; (al menos una vez) y etiqueta: LOOP ... LEAVE etiqueta; END LOOP; (ITERATE etiqueta salta a la siguiente vuelta).

Ciclo WHILE

6.7. Administrar procedimientos

6.8. Validaciones con SIGNAL

Igual que en los triggers, SIGNAL SQLSTATE '45000' detiene el procedimiento con un mensaje propio. Lo que se ejecutó antes del SIGNAL no se deshace solo (para eso, ver transacciones en 6.9):

El primer retiro (4 unidades) se hizo; los otros dos se rechazaron con su mensaje y el stock quedó en 6.

6.9. Transacciones y manejo de errores (HANDLER)

Una transacción agrupa varias operaciones que deben ocurrir todas o ninguna (explicadas en el módulo 5). Dentro de un procedimiento se combinan con un HANDLER, que define qué hacer si ocurre un error: EXIT sale del bloque y CONTINUE sigue con la siguiente instrucción. Lo habitual es un DECLARE EXIT HANDLER FOR SQLEXCEPTION que hace ROLLBACK, para que un error a mitad del proceso no deje cambios a medias.

La primera transferencia se aprueba; la segunda se rechaza por fondos insuficientes y los saldos no se alteran.

6.10. Cursores: recorrer un resultado fila por fila

Se usan cuando cada fila requiere un tratamiento individual. Siempre siguen estos pasos:

1. DECLARE cur CURSOR FOR SELECT ...; (después de las variables)
2. DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_fin = 1; (después del cursor)
3. OPEN cur; → ciclo con FETCH cur INTO ...; → CLOSE cur;

Si una sola sentencia SQL puede hacer el trabajo (por ejemplo, INSERT INTO bonos SELECT id, salario * 0.10 FROM empleados WHERE activo = 1), prefiérela: es más rápida que un cursor.

6.11. SQL dinámico y seguridad

Cuando una parte de la consulta (por ejemplo, el nombre de una tabla) solo se conoce al ejecutar, se arma como texto y se ejecuta con PREPARE / EXECUTE:

• Riesgo de inyección SQL: concatenar textos que vienen de un usuario permite que alguien "inyecte" SQL. Para valores, usa marcadores ? con EXECUTE sentencia USING @valor; para nombres de tablas, valida contra una lista de nombres permitidos.
• SQL SECURITY: por defecto un procedimiento se ejecuta con los permisos de quien lo creó (SQL SECURITY DEFINER). Con SQL SECURITY INVOKER usa los permisos de quien lo llama. Se escribe antes de BEGIN.

6.12. Errores comunes

• Usar SELECT COUNT(*) FROM t; esperando que llene un parámetro OUT: falta INTO p_total.
• Declarar variables después de otras instrucciones: todos los DECLARE van al inicio del bloque, en el orden variables → cursores → handlers.
• Llamar un procedimiento con OUT pasando un valor literal (CALL sp(5)): el parámetro de salida necesita una variable (@resultado).
• Nombrar un parámetro igual que una columna (id): genera ambigüedad. Usa prefijos como p_ y v_.
• Un ciclo WHILE sin SET i = i + 1 nunca termina.

6.13. Cómo responder en la plataforma

• Escribe una sola sentencia CREATE PROCEDURE con el nombre y los parámetros exactos del enunciado. No hace falta DELIMITER (qué es y cuándo se usa en la consola: sección 6.2).
• No incluyas el CALL: el sistema lo ejecuta por ti con valores de prueba y revisa el resultado.

7. Funciones almacenadas

7.1. ¿Qué es una función almacenada?

Una función almacenada recibe parámetros (solo de entrada) y devuelve exactamente un valor (un número, un texto o una fecha). Su gran ventaja es que se usa dentro de cualquier consulta, igual que UPPER() o ROUND(): en el SELECT, en WHERE, en ORDER BY o en GROUP BY.

7.2. Sintaxis general

Si el cálculo cabe en una línea, se puede omitir BEGIN ... END: CREATE FUNCTION fn_doble(n INT) RETURNS INT DETERMINISTIC RETURN n * 2;

7.3. Primera función: un cálculo (descuento + IVA)

7.4. Función vs. procedimiento

7.5. IF dentro de la función y uso en consultas

Una función puede tener varios RETURN (uno por cada camino del IF) y se puede usar incluso en GROUP BY:

7.6. Características: determinismo y acceso a datos

7.7. Administrar funciones

7.8. Funciones que leen otras tablas (READS SQL DATA)

COALESCE(SUM(total), 0) evita devolver NULL cuando el cliente no tiene pedidos (Eva).

7.9. Límites de las funciones

Una función no puede llamarse a sí misma. MySQL acepta crearla, pero falla al usarla:

• Para cálculos repetitivos usa un ciclo (WHILE) dentro de la función, o una CTE recursiva en la consulta (sección 4.16).
• Una función no puede devolver un conjunto de filas: un SELECT sin INTO dentro de ella da error 1415. Si necesitas devolver filas, usa un procedimiento (6.4) o una vista (2.8).
• No admite START TRANSACTION, COMMIT, ROLLBACK ni SQL dinámico (PREPARE).

7.10. Rendimiento

• Una función usada en el SELECT se ejecuta una vez por fila. Si además consulta otras tablas (7.8), en una tabla con miles de filas se ejecutan miles de consultas: a veces un JOIN con GROUP BY es mucho más rápido.
• Una función aplicada a una columna en el WHERE (WHERE fn_categoria(id) = 'ORO') impide usar los índices de esa columna: MySQL debe calcularla para todas las filas.

7.11. Errores comunes

• Olvidar RETURNS tipo (antes de BEGIN) o el RETURN valor; dentro del cuerpo.
• Confundir RETURNS (declara el tipo, va en la cabecera) con RETURN (devuelve el valor, va en el cuerpo).
• Escribir IN antes de los parámetros: en las funciones de MySQL (y de esta versión de MariaDB) es un error de sintaxis.
• Un SELECT sin INTO dentro de la función produce error: una función no puede devolver un conjunto de resultados.
• Tipo de retorno muy pequeño (DECIMAL(5,2) para valores grandes) provoca truncamiento o error.

7.12. Cómo responder en la plataforma

• Escribe una sola sentencia CREATE FUNCTION con el nombre, parámetros y tipo de retorno exactos. No hace falta DELIMITER (qué es y cuándo se usa en la consola: sección 6.2).
• Incluye DETERMINISTIC (o la característica que pida el reto). El sistema invoca tu función con valores de prueba y compara el resultado.

8. Disparadores (Triggers)

8.1. ¿Qué es un disparador y para qué sirve?

Un disparador (trigger) es un bloque de código SQL asociado a una tabla que el motor ejecuta automáticamente cuando ocurre un INSERT, UPDATE o DELETE sobre ella. Nadie lo llama: reacciona a los cambios. Se ejecuta una vez por cada fila afectada (FOR EACH ROW).

8.2. Sintaxis general

Si el cuerpo tiene una sola instrucción, BEGIN ... END es opcional. Convención útil para el nombre: tg_tabla_bi (before insert), _au (after update), _bd (before delete)…

Para escribir un trigger con BEGIN ... END en la consola hay que usar DELIMITER, igual que con los procedimientos (6.2).

8.3. Momento y evento: la matriz de activación

8.4. Pseudorregistros OLD y NEW

• NEW: la fila como va a quedar. Existe en INSERT y UPDATE. Solo en BEFORE puedes modificarla con SET NEW.columna = valor;.
• OLD: la fila como estaba. Existe en UPDATE y DELETE. Es de solo lectura.
• Usar NEW en un trigger de DELETE (o OLD en uno de INSERT) produce error al crearlo: "There is no NEW row in on DELETE trigger".

8.5. Primer trigger: BEFORE INSERT para corregir datos

El precio negativo se convierte en 0 y el nombre se guarda en mayúsculas, sin que quien inserta tenga que hacerlo.

8.6. AFTER INSERT, AFTER UPDATE y BEFORE DELETE

AFTER INSERT: descontar inventario

Cada venta descuenta su cantidad del stock. El trigger se ejecuta una vez por fila insertada (3 veces aquí).

AFTER UPDATE: historial comparando OLD y NEW

Se actualizan dos empleados, pero solo a Ana le cambió el salario: por eso hay un único registro en el historial.

BEFORE DELETE: respaldar la fila que se borra

8.7. Variables locales e IF dentro del trigger

Dentro de BEGIN ... END se pueden declarar variables (DECLARE, siempre al inicio) y usar IF ... ELSEIF ... ELSE ... END IF o CASE, igual que en un procedimiento.

La venta de 60.000 se guardó sin cambios; la de 200.000 superó el límite y quedó en 180.000 (10 % de descuento).

8.8. Administrar disparadores

8.9. Bloquear una operación con SIGNAL

SIGNAL SQLSTATE '45000' lanza un error definido por ti: la sentencia que activó el trigger se cancela y el mensaje llega a la aplicación. Observa que Tomás nunca se guardó.

8.10. Varios triggers en el mismo evento: FOLLOWS y PRECEDES

Una tabla puede tener varios triggers para el mismo momento y evento (MySQL 5.7+ y MariaDB 10.2+). Por defecto se ejecutan en el orden en que se crearon; con FOLLOWS otro (después de) o PRECEDES otro (antes de) se fija el orden:

tg_preparar se creó de último, pero se ejecutó primero porque se declaró PRECEDES tg_validar.

8.11. Triggers y llaves foráneas en cascada

Un detalle importante: las acciones automáticas de una llave foránea (ON DELETE CASCADE, ON UPDATE CASCADE) no activan los triggers de la tabla hija.

Se borraron las dos líneas (10 directamente y 11 en cascada al borrar el pedido), pero la bitácora solo registró la 10. Si necesitas auditar también los borrados en cascada, haz el borrado de las filas hijas explícitamente (o desde un procedimiento) en lugar de depender de CASCADE.

8.12. Restricciones y errores comunes

• Modificar la misma tabla del trigger (por ejemplo, un UPDATE productos dentro de un trigger de productos) produce el error 1442 "Can't update table ... because it is already used by statement which invoked this trigger". Para cambiar la fila actual usa SET NEW.columna en un trigger BEFORE.
• No se permiten START TRANSACTION, COMMIT ni ROLLBACK dentro de un trigger: forma parte de la transacción de la sentencia que lo activó. Si el trigger falla, la sentencia completa se cancela.
• Un trigger no puede llamarse a sí mismo en cadena (recursión) ni devolver resultados con un SELECT sin INTO.
• Rendimiento: se ejecuta por cada fila. Un UPDATE que afecta 100.000 filas ejecuta el trigger 100.000 veces; mantén su lógica sencilla.
• SET NEW.col en un trigger AFTER da error: la fila ya se guardó.
• Olvidar END IF; o el ; al final de cada instrucción dentro de BEGIN ... END.

8.13. Cómo responder en la plataforma

• Escribe una sola sentencia CREATE TRIGGER con el nombre exacto que pide el reto. No hace falta DELIMITER (si lo pones, se ignora).
• Las tablas ya existen: no las crees. El sistema ejecuta tu trigger, realiza una operación de prueba y revisa el efecto en los datos.
• En los retos de corrección, reescribe la sentencia completa ya corregida.

9. Eventos programados (Event Scheduler)

9.1. ¿Qué es un evento?

Un evento es una tarea SQL que el propio servidor ejecuta automáticamente según un horario: una sola vez en una fecha concreta o de forma repetida (cada hora, cada día…). Es como una alarma o un "cron" dentro de la base de datos: sirve para limpiar datos viejos, generar resúmenes nocturnos, cerrar periodos, etc.

9.2. Activar el programador de eventos

9.3. Sintaxis general

Unidades válidas: SECOND, MINUTE, HOUR, DAY, WEEK, MONTH, QUARTER, YEAR (en singular). EVERY siempre necesita cantidad y unidad: EVERY 1 DAY, nunca EVERY DAY.

9.4. Primer evento: una sola vez

Se programa para "ahora mismo"; unos instantes después, el servidor ya lo ejecutó y el valor cambió de 0 a 1.

9.5. STARTS, ENDS y ON COMPLETION

• ON COMPLETION NOT PRESERVE (valor por defecto): cuando un evento AT se ejecuta, o un evento EVERY llega a su ENDS, MySQL lo elimina automáticamente.
• ON COMPLETION PRESERVE: el evento se conserva (queda deshabilitado) para poder revisarlo o reactivarlo sin reescribirlo.

9.6. Eventos que se repiten: limpieza diaria

Con STARTS CURRENT_TIMESTAMP la primera ejecución es inmediata; luego se repetirá cada día. Las sesiones de hace 10 y 30 días se eliminaron.

9.7. Administrar eventos

9.8. Eventos que llaman procedimientos

La práctica recomendada es dejar la lógica en un procedimiento y que el evento solo lo llame: así se puede probar con CALL y cambiar sin tocar el horario.

La reserva que venció hace 2 días pasó a "vencida"; la que vence en 5 días sigue activa.

9.9. Consultar el estado de los eventos

El catálogo information_schema.EVENTS muestra el tipo, la frecuencia, la fecha programada y si están activos:

RECURRING = se repite; ONE TIME = una sola vez (AT). La columna LAST_EXECUTED indica cuándo se ejecutó por última vez.

9.10. Errores silenciosos y buenas prácticas

Cuando un evento falla no aparece ningún mensaje, porque no hay un usuario conectado que lo vea. El error solo queda en el registro de errores del servidor, en XAMPP: C:\xampp\mysql\data\mysql_error.log. Así se ve allí el evento ev_limpieza del ejemplo anterior, que borra de una tabla que no existe:

• Prueba la lógica antes como consulta normal o con CALL (por eso conviene usar procedimientos, 9.8).
• Lleva una bitácora: que el procedimiento registre en una tabla cada ejecución (fecha, filas afectadas con ROW_COUNT(), y un HANDLER que guarde los errores).
• Hora del servidor: los horarios usan la zona horaria de MySQL (SELECT NOW();), que puede ser distinta a la de tu equipo o a la de la aplicación.
• Ejecuciones que se solapan: si una ejecución tarda más que el intervalo (por ejemplo, EVERY 1 MINUTE con una tarea de 2 minutos), puede comenzar otra antes de que termine la anterior.
• Para crear eventos el usuario necesita el privilegio EVENT sobre la base de datos.

9.11. Errores comunes

• EVERY DAY o EVERY 1 DAYS: la sintaxis correcta es EVERY 1 DAY.
• Olvidar la palabra DO antes del cuerpo.
• Programador apagado (event_scheduler = OFF): el evento existe pero nunca se ejecuta.
• Una fecha en el pasado con AT (sin PRESERVE): MySQL descarta el evento en el momento de crearlo, sin ejecutarlo, y solo muestra una advertencia.

9.12. Cómo responder en la plataforma

• Escribe una sola sentencia CREATE EVENT con el nombre y el horario que pide el reto. No hace falta DELIMITER (qué es y cuándo se usa en la consola: sección 6.2).
• Para comprobarlo, el sistema revisa la programación de tu evento, ejecuta una vez su cuerpo (lo que va después de DO), como lo haría el programador de eventos, y revisa el efecto en los datos. No hace falta tener encendido event_scheduler.

10. Usuarios, roles y permisos (DCL)

El DCL (Data Control Language) decide quién puede entrar al servidor y qué puede hacer en cada base, tabla o columna. Sus sentencias principales son GRANT (dar permisos) y REVOKE (quitarlos); junto a ellas se usan CREATE USER y CREATE ROLE.

10.1. ¿Por qué no trabajar siempre con root?

root puede hacer cualquier cosa en cualquier base: borrar bases completas, ver todos los datos o crear usuarios. Si una aplicación se conecta como root y alguien encuentra una falla en ella, tiene el servidor completo. Lo correcto es aplicar el principio de mínimo privilegio: cada usuario o aplicación recibe solo los permisos que necesita.

10.2. Crear, modificar y eliminar usuarios

Un usuario se identifica por su nombre y por el equipo desde donde se conecta: 'nombre'@'equipo'.

• 'localhost' = solo desde el mismo equipo del servidor; '%' = desde cualquier equipo; '192.168.1.%' = desde la red local. 'ana'@'localhost' y 'ana'@'%' son dos usuarios distintos, cada uno con sus permisos.
• Un usuario recién creado puede conectarse pero no puede hacer nada: no tiene permisos hasta que se le den con GRANT (10.3).
• Para conectarse con él, desde CMD: mysql -u ana -p (pide la contraseña).

10.3. Dar y quitar permisos: GRANT y REVOKE

• Estructura: GRANT permisos ON dónde TO quién; y REVOKE permisos ON dónde FROM quién;.
• SHOW GRANTS muestra los permisos actuales. USAGE significa "puede conectarse, pero sin permisos": siempre aparece. La contraseña se guarda cifrada, nunca en texto.
• Los cambios con GRANT y REVOKE se aplican de inmediato; no hace falta FLUSH PRIVILEGES (solo se necesita si se modifican a mano las tablas de mysql).
• Si el usuario intenta algo sin permiso recibe un error y la operación no se hace. Por ejemplo, ana puede leer y modificar mascotas (10.5), pero no borrarlas:

10.4. Niveles de permiso: servidor, base, tabla, columna y rutina

La parte ON del GRANT decide a qué se aplica el permiso. Elige siempre el nivel más pequeño que sirva:

Con el permiso por columnas, luis puede ver el nombre de las mascotas, pero no el costo de la consulta:

10.5. Roles: permisos agrupados

Cuando varias personas hacen el mismo trabajo (por ejemplo, todo el personal de recepción), dar los mismos permisos uno por uno es repetitivo y fácil de equivocar. Un rol es un conjunto de permisos con nombre: se le dan los permisos al rol y luego se asigna el rol a cada usuario. Si cambian las tareas, se modifica el rol una sola vez.

Importante: tener un rol asignado no basta; el rol debe estar activo en la sesión. ana lo tiene como rol por defecto, así que se activa solo al conectarse. luis tiene el rol, pero no por defecto: hasta que no ejecuta SET ROLE solo cuenta con sus permisos propios.

Al cambiar los permisos del rol, el cambio llega a todos sus usuarios. Por ejemplo, para que recepción ya no pueda modificar:

10.6. Dar acceso solo a vistas o procedimientos

A veces un usuario no debe ver la tabla completa ni modificarla libremente. En lugar de darle permisos sobre la tabla:

• Se le da SELECT sobre una vista (2.8) que muestra solo las columnas o filas permitidas.
• Se le da EXECUTE sobre un procedimiento (módulo 6) que hace la operación con sus propias reglas. Con SQL SECURITY DEFINER (el valor por defecto) el procedimiento usa los permisos de quien lo creó, así que el usuario puede registrar datos sin tener permiso directo sobre la tabla.

Conectado como web:

web ve las mascotas sin el costo de la consulta y puede registrar una mascota solo a través del procedimiento, que fija el costo. No puede leer la tabla ni insertar directamente en ella.

10.7. Buenas prácticas

• Un usuario por aplicación o persona, nunca una cuenta compartida: así se sabe quién hizo qué y se puede quitar el acceso a uno solo.
• Mínimo privilegio: empieza sin permisos y agrega solo los necesarios, en el nivel más pequeño (tabla o columna antes que base; base antes que servidor).
• Las aplicaciones nunca se conectan como root. Esta misma plataforma ejecuta el código de los aprendices con un usuario que solo puede trabajar en bases temporales de prueba.
• Usa roles cuando varias personas comparten las mismas tareas, y revisa los permisos con SHOW GRANTS de vez en cuando.
• Prefiere 'usuario'@'localhost' o una red concreta antes que '%', y contraseñas largas que no se escriban en archivos ni en el código.
• Cuando alguien deja de necesitar el acceso, quítalo de inmediato (REVOKE o DROP USER).

10.8. Chuleta

11. Copias de seguridad y restauración

11.1. Sacar una copia de seguridad con mysqldump

Se ejecuta en CMD, fuera de la consola de MySQL, desde C:\xampp\mysql\bin (o desde el Shell de XAMPP):

El símbolo > le dice a CMD que guarde en un archivo lo que el programa mostraría en pantalla. Si el archivo ya existe, se reemplaza. La carpeta de destino debe existir (créala antes con mkdir C:\respaldos).

Opciones útiles que se pueden combinar:

• --routines --events: importante en este curso. Sin ellas, los procedimientos, funciones y eventos que creaste no quedan en la copia.
• --single-transaction: copia consistente de tablas InnoDB sin bloquearlas mientras otros usuarios trabajan.
• --skip-extended-insert: un INSERT por fila (archivo más largo, pero más fácil de leer y comparar).
• --default-character-set=utf8mb4: conserva bien tildes y eñes.
• --result-file=C:\respaldos\copia.sql: alternativa a >.

Ejemplo de una copia completa recomendada para el curso:

Si el comando no muestra nada después de la contraseña, terminó bien: mysqldump solo imprime mensajes cuando hay errores.

11.2. ¿Qué contiene el archivo .sql que se genera?

Un respaldo es un archivo de texto con las sentencias SQL necesarias para reconstruir la base. Este es el archivo real que genera mysqldump para la base veterinaria, con la explicación de cada parte:

Diferencias según la opción usada (misma base de ejemplo):

Lo que agrega --databases al inicio del archivo:

11.3. Cargar (restaurar) una base de datos desde un archivo .sql

Se usa el cliente mysql y el símbolo <, que le entrega el contenido del archivo como si lo escribieras. Hay dos casos:

Caso 1: el archivo NO trae CREATE DATABASE (copia normal, --no-data o --no-create-info)

Primero crea la base vacía y luego carga el archivo indicando en qué base:

-e "..." ejecuta una sola sentencia sin entrar a la consola. Igual que mysqldump, si no muestra nada, terminó bien.

Caso 2: el archivo SÍ trae CREATE DATABASE (copia hecha con --databases o --all-databases)

No se indica base de destino: el archivo la crea y la selecciona con USE. Ojo: siempre se restaura con el nombre original.

Alternativa: cargar desde dentro de la consola con SOURCE

Con SOURCE la ruta va con barras / (o dobles \\) y se ve el resultado de cada sentencia, lo que ayuda a encontrar en qué línea falla.

Comprobar que la restauración quedó bien

Errores frecuentes al restaurar

11.4. Automatizar los respaldos

Un archivo .bat guarda los comandos para no escribirlos cada vez. Crea con el Bloc de notas C:\respaldos\respaldo_diario.bat:

• Cada ejecución crea un archivo con la fecha (veterinaria_2026-10-13.sql) y borra los de más de 30 días.
• El ejemplo usa root sin contraseña (XAMPP recién instalado). Si root tiene contraseña, no la escribas en el .bat: crea un usuario solo para respaldos (10.4).
• Programarlo: en Windows, abre el Programador de tareas → Crear tarea básica → frecuencia Diariamente → acción Iniciar un programa → selecciona el .bat.
• Revisa de vez en cuando que el archivo termine en -- Dump completed y prueba restaurarlo (11.3).

11.5. Buenas prácticas de respaldo

• Prueba tus copias: una copia que nunca restauraste no está comprobada. Restáurala en una base distinta (_copia) y revisa tablas y conteos.
• Nombra los archivos con la fecha (tienda_2026-10-12.sql) y conserva varias versiones, no solo la última.
• Guarda las copias fuera del equipo (memoria USB, nube): si el disco falla, la copia en el mismo disco se pierde con él.
• Antes de un cambio grande (borrar datos, modificar tablas), haz una copia.
• Revisa que el archivo termine en -- Dump completed.

11.6. Chuleta