ERROR 1049: Unknown database

El ERROR 1049 aparece cuando le pides a MySQL que trabaje con una base de datos que, desde su punto de vista, no existe. Puede surgir al conectarte indicando una base de datos en la línea de comandos, al ejecutar USE dentro de una sesión o al arrancar una aplicación cuya configuración apunta a una base concreta. Es un error sencillo en apariencia, pero tiene una trampa: muchas veces la base de datos sí existe, solo que en otro servidor, con otro nombre o con otras mayúsculas.

La buena noticia es que, igual que ocurre con el ERROR 1045 Access denied, este error ya te dice mucho. Si ves el 1049, la conexión con el servidor se ha establecido y la autenticación ha funcionado, así que puedes descartar problemas de red, de socket o de contraseña. El problema está en el nombre de la base de datos o en el servidor al que realmente te has conectado. En este artículo verás cómo leer el mensaje, las causas más frecuentes, cómo diagnosticar cuál es la tuya y cómo resolverlo.

El mensaje de error

El mensaje tiene una estructura muy simple. Incluye el código, el estado SQL 42000 y el nombre exacto de la base de datos que MySQL no ha encontrado:

ERROR 1049 (42000): Unknown database 'tienda_mysql'

Fíjate bien en el nombre que aparece entre comillas, porque es el nombre tal como lo recibió el servidor, carácter a carácter. Si hay una errata, una mayúscula de más o un espacio que no esperabas, lo verás ahí. Desde una aplicación, el mismo error llega envuelto en el formato del conector. Con PDO en PHP, por ejemplo, el mensaje tiene este aspecto:

SQLSTATE[HY000] [1049] Unknown database 'tienda_mysql'

El código 1049 es lo que importa, independientemente del lenguaje o del framework. Si lo ves al arrancar la aplicación, casi siempre significa que la configuración de conexión apunta a una base de datos que no existe en ese servidor.

Cuándo aparece

El error puede aparecer en dos momentos distintos. El primero es al conectar, cuando indicas la base de datos en la propia conexión, ya sea con la opción -D o como último argumento del cliente mysql:

mysql -u app_tienda -p -D tienda_mysql
mysql -u app_tienda -p tienda_mysql

El segundo es dentro de una sesión ya abierta, al cambiar de base de datos con USE, que se explica con detalle en el artículo sobre cómo seleccionar una base de datos:

USE tienda_mysql;

En ambos casos la causa es la misma, pero distinguirlos ayuda: si conectarte sin indicar base de datos funciona y el error aparece solo al añadirla, sabes que el servidor y las credenciales están bien.

Causas más habituales

La causa más obvia es que la base de datos todavía no se ha creado. Ocurre constantemente al montar un entorno nuevo: clonas un proyecto, configuras la aplicación y la arrancas antes de haber ejecutado CREATE DATABASE. MySQL no crea bases de datos automáticamente al conectarse a ellas, así que el primer intento falla con 1049. Lo mismo sucede cuando intentas restaurar un dump en una base que aún no existe.

La segunda causa, igual de frecuente, es una simple errata en el nombre. tienda_mysql y tienda-mysql son nombres distintos, igual que tiendamysql o tienda_mysql con un espacio al final copiado de algún sitio. El mensaje de error muestra el nombre exacto, así que compararlo letra a letra con el resultado de SHOW DATABASES suele resolver el misterio en segundos.

Mayúsculas y minúsculas en Linux

En MySQL, cada base de datos se guarda como un directorio dentro del directorio de datos del servidor. Eso significa que la distinción entre mayúsculas y minúsculas depende del sistema operativo y de la variable lower_case_table_names. En Linux, el valor por defecto es 0, así que los nombres de bases de datos distinguen mayúsculas: Tienda y tienda son dos bases diferentes. En Windows el valor por defecto es 1 y en macOS es 2, y en ambos casos los nombres no distinguen mayúsculas en la práctica.

Esto provoca un caso clásico: una aplicación que funciona en el portátil de desarrollo con Windows o macOS falla en el servidor Linux con Unknown database 'Tienda', porque allí la base se creó como tienda. Puedes consultar el valor en tu servidor con esta consulta:

SELECT @@lower_case_table_names;

La solución es usar siempre nombres en minúsculas, tanto al crear la base de datos como en la configuración de la aplicación. Cambiar lower_case_table_names en un servidor ya inicializado no es una opción razonable, porque en MySQL 8 solo puede establecerse al inicializar el directorio de datos.

Conectarte a otro servidor

Una causa muy desconcertante es que la base de datos exista, pero en otro servidor distinto al que te estás conectando. Es habitual cuando en la misma máquina conviven varias instancias de MySQL: una instalada en el sistema y otra en Docker, o dos contenedores con puertos distintos. Si la base está en el contenedor que escucha en el puerto 3307 y tú te conectas al 3306, el servidor que responde es otro y, lógicamente, no la conoce.

Algo parecido ocurre con localhost y 127.0.0.1. En sistemas tipo Unix, localhost hace que el cliente use el socket local, mientras que 127.0.0.1 fuerza una conexión TCP. Si el MySQL del sistema escucha en el socket y un contenedor Docker publica el puerto 3306, cada forma de conectarte puede llevarte a un servidor distinto. Si has tenido problemas con el socket, el artículo sobre el ERROR 2002 Can't connect explica esta diferencia con detalle.

Docker y la variable MYSQL_DATABASE

Con la imagen oficial de MySQL en Docker es muy común definir la variable MYSQL_DATABASE para que el contenedor cree la base de datos al arrancar. Lo que mucha gente no sabe es que los scripts de inicialización de la imagen solo se ejecutan cuando el directorio de datos está vacío, es decir, la primera vez que se crea el volumen:

services:
  mysql:
    image: mysql:8.4
    environment:
      MYSQL_ROOT_PASSWORD: secreto
      MYSQL_DATABASE: tienda_mysql
    volumes:
      - datos_mysql:/var/lib/mysql

Si el volumen datos_mysql ya existía de una ejecución anterior, cambiar MYSQL_DATABASE no tiene ningún efecto: el contenedor arranca con los datos antiguos y la nueva base no se crea. La solución es crear la base manualmente con CREATE DATABASE o, si el entorno es desechable, eliminar el volumen para que la inicialización vuelva a ejecutarse.

La configuración de la aplicación

En aplicaciones web, el nombre de la base de datos suele venir de un fichero de configuración o de variables de entorno. En Laravel, por ejemplo, está en la variable DB_DATABASE del fichero .env:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=tienda_mysql
DB_USERNAME=app_tienda
DB_PASSWORD=ClaveSegura2026

Si ese valor no coincide con una base existente en el servidor indicado por DB_HOST y DB_PORT, la aplicación falla con 1049 en la primera consulta. Revisa también que la aplicación esté leyendo el fichero que crees: una caché de configuración antigua o un .env de otro entorno pueden hacer que se use un nombre distinto al que ves en el editor.

Errores parecidos que no son el 1049

Hay dos situaciones que se confunden a menudo con este error y que conviene distinguir. La primera es usar un nombre con guiones sin comillas invertidas. Si ejecutas USE mi-tienda;, MySQL no interpreta el guion como parte del nombre, sino como un signo menos, así que el error que obtienes no es el 1049, sino un error de sintaxis, el ERROR 1064. Para usar ese nombre debes escribirlo entre comillas invertidas:

USE `mi-tienda`;

La segunda situación tiene que ver con los permisos. Si tu usuario no tiene ningún privilegio sobre una base de datos, MySQL no responde con 1049, sino con un error de acceso distinto:

ERROR 1044 (42000): Access denied for user 'app_tienda'@'localhost' to database 'tienda_mysql'

Para un usuario sin privilegios sobre ella, MySQL devuelve este mismo 1044 tanto si la base existe como si no, precisamente para no revelar qué bases de datos hay en el servidor. En la práctica, eso significa que el 1049 lo ven sobre todo los usuarios con privilegios amplios, como root, o los que tienen permisos sobre un patrón de nombres que incluye la base que buscan.

Cómo diagnosticar el problema

El primer paso es conectarte sin indicar ninguna base de datos y comprobar cuáles ve tu usuario en ese servidor. Recuerda que SHOW DATABASES solo muestra las bases sobre las que tienes algún privilegio, algo que se explica en el artículo sobre SHOW DATABASES:

SHOW DATABASES;

Si la lista es larga, puedes filtrarla con un patrón para buscar variantes del nombre, como mayúsculas distintas o sufijos:

SHOW DATABASES LIKE '%tienda%';

Si la base no aparece, el siguiente paso es confirmar a qué servidor estás conectado realmente. Esta consulta devuelve el nombre de la máquina y el puerto del servidor que te está respondiendo, lo que permite detectar enseguida si has acabado en otra instancia o en otro contenedor:

SELECT @@hostname, @@port, VERSION();

Si el nombre de host o el puerto no son los que esperabas, el problema no está en la base de datos, sino en los parámetros de conexión. Si todo coincide y la base sigue sin aparecer, es que realmente no existe en ese servidor y hay que crearla.

Soluciones paso a paso

La solución más habitual es crear la base de datos. Usar IF NOT EXISTS hace que la sentencia sea segura aunque la ejecutes más de una vez, y conviene indicar siempre el conjunto de caracteres para evitar problemas con acentos y emojis. El artículo sobre CREATE DATABASE explica todas las opciones:

CREATE DATABASE IF NOT EXISTS tienda_mysql
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_0900_ai_ci;

Si la base la va a usar una aplicación con su propio usuario, después de crearla debes darle permisos sobre ella. Sin este paso, el usuario de la aplicación pasaría a recibir el 1044 que vimos antes:

GRANT SELECT, INSERT, UPDATE, DELETE ON tienda_mysql.* TO 'app_tienda'@'localhost';

Si necesitas ajustar los privilegios con más detalle, el artículo sobre GRANT explica cómo concederlos a nivel de base de datos, tabla o columna.

Al restaurar un dump

Un caso muy frecuente es encontrarse el error al importar una copia de seguridad. Si ejecutas la restauración indicando el nombre de la base de datos, esa base tiene que existir antes, porque el cliente se conecta a ella antes de leer el fichero:

mysql -u root -p tienda_mysql < tienda_mysql.sql

Si la base no existe, este comando falla inmediatamente con 1049. Tienes dos opciones. La primera es crear la base vacía con CREATE DATABASE y repetir el comando. La segunda es generar el dump con la opción --databases, que incluye en el propio fichero las sentencias CREATE DATABASE y USE, de modo que puedes restaurarlo sin indicar ninguna base:

mysqldump -u root -p --databases tienda_mysql > tienda_mysql.sql
mysql -u root -p < tienda_mysql.sql

El proceso completo de importación, con sus opciones y precauciones, se explica en el artículo sobre cómo restaurar un dump.

Cómo evitar el error

La forma más eficaz de evitar el 1049 es que la creación de la base de datos forme parte del proceso de instalación del proyecto y no dependa de la memoria de nadie. Un script de inicialización con CREATE DATABASE IF NOT EXISTS, un fichero SQL en el directorio de inicialización de Docker o un paso documentado en el README bastan para que cualquier entorno nuevo arranque con la base creada.

También ayuda mucho adoptar una convención de nombres estricta: solo minúsculas, números y guiones bajos, sin guiones ni espacios. Así evitas tanto los problemas de mayúsculas entre sistemas operativos como la necesidad de comillas invertidas en USE. Y cuando trabajes con varias instancias en la misma máquina, acostúmbrate a indicar siempre el host y el puerto de forma explícita y a comprobar con SELECT @@hostname, @@port dónde estás conectado antes de tocar nada.

Resumen

El ERROR 1049 (42000): Unknown database indica que el servidor ha aceptado tu conexión, pero no tiene ninguna base de datos con el nombre que le has pedido. Las causas más comunes son que la base no se ha creado, una errata o diferencia de mayúsculas en el nombre, conectarse a otra instancia de MySQL o una configuración de la aplicación que apunta a un nombre incorrecto. Para diagnosticarlo, conéctate sin base de datos, revisa SHOW DATABASES y confirma el servidor con @@hostname y @@port; para resolverlo, casi siempre basta con CREATE DATABASE y los permisos adecuados. Si en lugar del 1049 ves un 1044, el problema son los privilegios de tu usuario, y si el error aparece una vez dentro de la base, al consultar una tabla concreta, estás ante un problema distinto: el ERROR 1146 Table doesn't exist.