Cuando trabajas con MySQL, las llaves y los índices son la diferencia entre una consulta que tarda milisegundos y una que devora recursos del servidor. Aprender a usarlos bien te permite garantizar la integridad de tus datos y acelerar hasta ocho veces tus búsquedas, algo que se traduce en dinero ahorrado en infraestructura cloud y en respuestas más rápidas para tus usuarios.

Qué diferencia hay entre llaves e índices en MySQL

Aunque suelen mencionarse juntos, son conceptos distintos que terminan cruzándose en el mismo lugar: la velocidad y la integridad de tus datos [01:00].

Una llave garantiza la integridad de la información. En MySQL existen tres tipos principales:

• Primary key: identifica de forma única cada tupla, normalmente sobre la columna id.
• Unique key: asegura que un valor en una columna ocurra una y solo una vez, como el email en una tabla de clientes.
• Foreign key: crea una relación dura entre tablas y mantiene la normalización completa.

Un índice, en cambio, es una estructura interna que MySQL mantiene casi invisible para ti. Guarda metadatos ordenados sobre los valores de una columna para que las búsquedas sean mucho más rápidas [03:00]. Usa algoritmos como B-Tree para optimizar el acceso.

¿Toda llave es un índice? Sí, todas las llaves primarias son índices automáticamente. Pero no todos los índices son llaves: puedes indexar columnas que no son únicas ni primarias.

Cómo crear un índice y cuánto acelera las consultas

La regla práctica es indexar las columnas que más usas en los queries críticos, sobre todo en las cláusulas where y order by [12:00]. La parte de impresión, lo que aparece después de select, no afecta al índice.

En una tabla clients con 100.000 registros, una búsqueda por nombre sin índice tardaba 0.08 segundos. Después de crear el índice con:

sql CREATE INDEX idx_clients_name ON clients(name);

La misma consulta bajó a menos de 0.01 segundos [06:00]. Es al menos ocho veces más rápido, y esa ganancia se mantiene consistente, no depende de si el servidor tiene un buen día.

¿Qué cuesta crear un índice en MySQL? Espacio en disco duro. Es un costo real al que hay que prestarle atención porque puede llenar tu almacenamiento sin que te des cuenta, pero suele ser mucho menor que el ahorro en tiempo de CPU.

Por qué el orden de las columnas en un índice compuesto es crucial

Cuando creas un índice sobre dos columnas, el orden lo cambia todo. No es lo mismo:

sql CREATE INDEX a ON clients(name, email); CREATE INDEX b ON clients(email, name);

MySQL almacena los valores ordenados según la secuencia que tú definas. Si tu query filtra primero por email y después por name, el índice que empieza por name no te dará la ventaja esperada [14:00].

Esto explica el error más común que se ve en producción: alguien crea un índice, no nota mejora y concluye que los índices no sirven. El problema casi siempre es que el orden del índice no coincide con el orden de las condiciones en el where.

¿Cuántas columnas conviene incluir en un índice? Una o dos suele ser lo más útil en la práctica. Más columnas pueden ayudar, pero hay que pensar bien qué amerita ser indexado según los queries que más se repiten.

Cuándo indexar columnas que no son únicas o numéricas

Un índice no necesita una columna unique. Puedes indexar un phone number tipo varchar que admite nulos y no tiene valor por defecto, simplemente porque es una columna por la que buscas seguido [17:00].

En la prueba, una búsqueda por teléfono sin índice tardó 0.08 segundos. Con índice, bajó a 0 segundos efectivos. La regla es la misma: si lo usas en el where, indexarlo te conviene.

También puedes indexar columnas numéricas como float para buscar precios, o columnas de fecha para tenerlas ordenadas. Un caso típico es indexar created_at de forma descendente para traer siempre los registros más nuevos primero:

sql CREATE INDEX idx_clients_created ON clients(created_at DESC);

El orden ascendente es el valor por defecto, pero puedes invertirlo si tu query habitual lo pide así [19:00]. En el ejemplo de la clase la diferencia fue pequeña porque los datos se insertaron en bulk con fechas casi idénticas, pero en una base de datos real con cientos de miles de tuplas y decenas de columnas para discriminar, esos microsegundos se convierten en dólares al cierre del mes en AWS o Google Cloud.

Qué columnas vale la pena indexar primero

Antes de crear índices a ciegas, revisa tu aplicación e identifica:

1. Los queries más frecuentes y críticos.
2. Las columnas que aparecen en el where y en el order by de esos queries.
3. El orden exacto en que esas columnas se evalúan, para replicarlo en el índice.

La magia está en que un buen índice te da velocidad consistente, no dependiente del estado del servidor. Y aunque MySQL pronto sumará tipos como JSON donde los índices funcionan distinto, dominar llaves e índices clásicos es la base para todo lo que viene.

¿Has detectado un query lento en tu base de datos al que le vendría bien un índice? Cuéntame en los comentarios cuál es y cómo lo resolverías.