create user mysql: guía práctica, sintaxis y casos reales

create user mysql es la operación básica para gestionar cuentas en una base de datos MySQL: crear un usuario correctamente implica elegir host, método de autenticación, permisos mínimos y políticas de seguridad. Este texto explica cuándo usar CREATE USER en lugar de confiar solo en GRANT, muestra diferencias entre versiones, da ejemplos prácticos y aborda errores habituales.

Sintaxis y diferencias según versión

La forma más directa para crear un usuario es CREATE USER. En MySQL 8.0 la sintaxis soporta opciones modernas como autenticación por plugin, expiración de contraseña y requisitos de complejidad. En versiones anteriores (5.6 / 5.7) algunas opciones no existían o se gestionaban con GRANT y modificaciones manuales en la tabla mysql.user.

Ejemplos típicos:

• Crear usuario local con contraseña: CREATE USER ‘app’@’localhost’ IDENTIFIED BY ‘S3cur3P@ss’;
• Crear usuario para una IP remota: CREATE USER ‘report’@’10.0.0.50’ IDENTIFIED BY ‘R3p0rt!’;
• Usar plugin de autenticación (MySQL 8): CREATE USER ‘svc’@’%’ IDENTIFIED WITH caching_sha2_password BY ‘Xyz!234’;

Atención a factores que cambian según versión:

• En MySQL 8 el plugin caching_sha2_password es el predeterminado; en 5.7 se usa mysql_native_password.
• En 8.0 se pueden crear usuarios con expiración de contraseña (PASSWORD EXPIRE INTERVAL) y bloqueo de cuentas (ACCOUNT LOCK).
• Evitar manipular directamente la tabla mysql.user salvo casos muy concretos en instalaciones antiguas.

Paso a paso: crear un usuario local y uno remoto

Crear un usuario es más que ejecutar una línea: implica definir alcance y riesgo. Este paso a paso funciona como checklist.

1. Conectar como un administrador (por ejemplo, root o un usuario con CREATE USER y GRANT OPTION).
2. Determinar host de conexión: localhost (aplicaciones en el mismo servidor) o IP/CIDR/»%» (remoto — evitar «%» si no es necesario).
3. Definir política de contraseña: longitud, complejidad y expiración.
4. Crear el usuario con la sintaxis adecuada según versión.
5. Asignar los permisos mínimos necesarios mediante GRANT o roles.
6. Verificar con SHOW GRANTS FOR ‘user’@’host’; y probar conexión desde el cliente objetivo.

Ejemplo combinado:

CREATE USER ‘app’@’192.168.1.10’ IDENTIFIED BY ‘AppP@ss2025’;

GRANT SELECT, INSERT, UPDATE ON inventory.* TO ‘app’@’192.168.1.10’;

FLUSH PRIVILEGES; (no siempre necesario en versiones modernas tras CREATE/GRANT).

Permisos, roles y buenas prácticas de seguridad

Asignar privilegios correctamente evita que una brecha en una cuenta cause un desastre. Reglas prácticas:

• Aplicar el principio de menor privilegio: conceder solo los permisos que la aplicación necesita.
• Preferir roles cuando la versión lo soporte: se crean con CREATE ROLE y simplifican auditoría y revocación.
• Restringir acceso por host y, si es posible, usar redes privadas o túneles (SSH/VPN).
• Habilitar políticas de contraseña y bloqueo de cuenta para prevenir ataques por fuerza bruta.

Ejemplo con rol:

CREATE ROLE ‘reader’;

GRANT SELECT ON sales.* TO ‘reader’;

CREATE USER ‘report’@’10.0.0.12’ IDENTIFIED BY ‘R3p0rt!’;

GRANT ‘reader’ TO ‘report’@’10.0.0.12’;

Errores comunes y cómo evitarlos

Algunas causas frecuentes de problemas al crear usuarios y sus soluciones:

• Uso indiscriminado de ‘%’: deja el servidor expuesto. Sustituir por IPs o subredes concretas.
• Dar GRANT ALL por defecto: muchas aplicaciones no requieren privilegios de administración. Revisar requerimientos funcionales antes de otorgar permisos.
• Confusión entre CREATE USER y GRANT: CREATE USER crea la cuenta; GRANT asigna permisos. En versiones antiguas, GRANT podía crear usuarios implícitamente, pero esa práctica complica el control.
• No revisar el plugin de autenticación: un cliente antiguo puede no soportar caching_sha2_password. Elegir el plugin según los clientes que se conectarán.
• Contraseñas fáciles o sin expiración: configurar políticas y auditar contraseñas periódicamente.

Casos prácticos y mini-casos

Mini-caso 1 — Aplicación web en servidor separado: la app necesita acceso a la base de datos de solo lectura para informes. Lo correcto:

• Crear usuario limitado al host de la app: CREATE USER ‘analytics’@’203.0.113.7’ IDENTIFIED BY ‘Analyt1cs!’;
• Conceder solo SELECT sobre bases específicas: GRANT SELECT ON reporting.* TO ‘analytics’@’203.0.113.7’;
• Auditar consultas y activar límites de conexión si procede.

Mini-caso 2 — Servicio interno con respaldo: el servicio de backup necesita permisos para LOCK TABLES y SELECT en todas las bases. Solución:

• Crear usuario restringido por IP interna y conceder permisos puntuales.
• Registrar el acceso en registros de auditoría y usar certificados si la infraestructura lo permite.

Recomendaciones finales y verificación

Tras crear usuarios, seguir este checklist de verificación:

• Ejecutar SHOW GRANTS FOR ‘user’@’host’; para confirmar permisos.
• Probar la conexión desde el host esperado con el cliente que usará la cuenta.
• Comprobar política de contraseñas y caducidad: ALTER USER ‘user’@’host’ PASSWORD EXPIRE INTERVAL 90 DAY; (si la versión lo soporta).
• Documentar la cuenta: propósito, acceso, responsable y fecha de creación.

Crear usuarios en MySQL no es solo ejecutar una instrucción: implica entender el contexto, la versión del servidor y las necesidades de seguridad. Volver a revisar permisos y policies periódicamente reduce riesgos operativos y facilita la detección de anomalías. Para operaciones cotidianas usar CREATE USER seguido de GRANT y roles cuando sea posible; en caso de migraciones entre versiones, revisar compatibilidad de plugins de autenticación.

Al aplicar estas prácticas y comandos reales se logrará un uso seguro y efectivo de create user mysql en entornos productivos.