Identificación de queries lentas
El primer paso para optimizar es encontrar las consultas problemáticas. En iLove Telecom, activa Slow Query Log desde la configuración de tu base de datos gestionada. Define long_query_time = 2 para registrar consultas que tomen más de 2 segundos. En MySQL, revisa el log con mysqldumpslow. En PostgreSQL, instala la extensión pg_stat_statements para identificar las queries más lentas y más ejecutadas. Cloud Monitor también ofrece dashboards predefinidos con las consultas de mayor impacto.
Uso de EXPLAIN y planes de ejecución
El comando EXPLAIN (o EXPLAIN ANALYZE en PostgreSQL) muestra cómo el motor ejecutará tu consulta. Identifica Full Table Scans (type: ALL en MySQL, Seq Scan en PostgreSQL), que indican falta de índice. Presta atención a rows (número de filas estimadas a examinar): si es muy superior al número de filas devueltas, la consulta puede optimizarse. En MySQL, EXPLAIN FORMAT=JSON ofrece detalles adicionales como el costo de cada operación.
Creación de índices efectivos
Los índices aceleran las búsquedas pero ralentizan las escrituras y consumen espacio. Crea índices en columnas usadas en WHERE, JOIN, ORDER BY y GROUP BY. Los índices compuestos (varias columnas) deben ordenar las columnas de mayor selectividad primero. Ejemplo: CREATE INDEX idx_usuario_activo ON pedidos (usuario_id, fecha DESC). Evita indexar columnas con baja cardinalidad (como género o estado booleano). Usa SHOW INDEX FROM tabla para revisar índices existentes.
Optimización de joins y subconsultas
Prefiere JOIN explícitos sobre subconsultas correlacionadas. Cuando el optimizador las transforma, el rendimiento puede ser equivalente, pero los JOINs son más legibles y predecibles. Usa EXISTS en lugar de IN cuando la subconsulta retorne muchas filas: WHERE EXISTS (SELECT 1 FROM detalles WHERE detalles.pedido_id = pedidos.id) suele ser más eficiente que WHERE id IN (SELECT pedido_id FROM detalles) en MySQL.
Paginação eficiente
Para paginación con OFFSET y LIMIT, el rendimiento se degrada en páginas profundas porque la base de datos debe escanear todas las filas anteriores. Usa cursor-based pagination con WHERE id > ? LIMIT 20 y un índice en la columna de ordenación. Esto mantiene la latencia constante independientemente del número de páginas. También considera la partición de tablas grandes por rango (ej. por mes) para mejorar el mantenimiento y la velocidad de consultas en tablas con millones de registros.