tablestudioapp/plugins

Cómo hacer consultas más rápidas con TableStudio

TableStudio mide, no solo adivina. Nunca recomiendes un índice o una reescritura por intuición cuando puedas probarlo con las herramientas siguientes. La mayoría son solo para PostgreSQL; en otros motores usa explain_query y razona a partir del plan.

Primero selecciona la conexión, como se describe en la skill de flujo de trabajo de base de datos. Prefiere ejecutar el análisis contra una base de datos con datos realistas. Una base de datos de desarrollo casi vacía da planes engañosos.

Encontrar qué es lento

• El usuario nombra una consulta o un endpoint: encuentra el SQL que ejecuta (del código o del registro del ORM), luego ve a "Diagnosticar una sentencia".
• "¿Por qué está lenta la base de datos?" Llama a slow_queries. Ordena las sentencias por tiempo total desde pg_stat_statements. Conserva el query_id de cada fila; las demás herramientas lo aceptan. Si la extensión no está instalada, la herramienta explica lo que implica activarla, así que transmite eso en lugar de instalarla sin preguntar.
• Ajuste amplio: workload_index_advisor encuentra los menos índices que cubren la mayor parte del tiempo de la base de datos y lista los índices existentes que nunca se usan.

Un chequeo de salud

Cuando el usuario pregunte qué le pasa a una base de datos, o quiera una revisión general, no cambies nada e informa:

1. database_health. Lee su lista unavailable antes de resumir: si hay entradas allí con resultados vacíos, significa que las comprobaciones se saltaron, no que todo está bien.
2. database_overview para el tamaño, las tablas más grandes y más ocupadas, y los recuentos de conexiones.
3. schema_issues (sin table) para problemas de diseño en toda la base de datos.

Pon los hallazgos más importantes primero, en lenguaje sencillo: qué está mal, qué cuesta si se ignora y la solución. Incluye el verify_sql de cada hallazgo para que el usuario pueda verificar el número, y cualquier lock_impact de la solución. Ofrece poner las soluciones que el usuario elija a través de "Enviar" más abajo.

Diagnosticar una sentencia

1. optimize_query con el SQL (y query_id si vino de slow_queries). Para una sentencia de solo lectura, pasa analyze: true para que se ejecuten las comprobaciones medidas. Se ejecuta una vez dentro de una transacción revertida. Informa already_fast cuando no hay nada que valga la pena hacer; dilo en lugar de inventar una mejora.
2. Para más detalle, usa explain_query (analyze: true solo para lecturas). Compara actual_rows con estimated_rows en cada nodo. Una gran diferencia significa estadísticas obsoletas (ANALYZE la tabla), que a menudo es el verdadero error en lugar de un índice faltante.
3. Una sentencia con marcadores de posición $1, $2 necesita valores reales para planificar correctamente. suggest_parameter_values los encuentra a partir del historial, sesiones activas y estadísticas.

Probar la solución

Usa benchmark_query_variants (el Laboratorio de Consultas) antes de recomendar nada:

• Dale el SQL base y los candidatos como variants: un sql reescrito, hypothetical_indexes (planificados con hypopg, nunca construidos), hide_indexes o ajustes de planificador (settings). O deja variants fuera y deja que find_faster proponga los suyos.
• Informa las medianas de varias ejecuciones para cada conjunto de parámetros y comprueba que cada reescritura devuelva las mismas filas que la línea base.
• Solo recomienda una variante cuyo same_rows sea sí. Prefiere la variante en recommendation. Cita los valores medidos antes y después, no porcentajes por intuición.

Antes de eliminar un índice (no usado o duplicado), ejecuta index_what_if con él en hide. Cualquier sentencia que se vuelva más cara, o que use el índice hoy, se vería perjudicada.

Enviar

Los índices y las reescrituras pasan por el flujo de cambios normal de la skill de flujo de trabajo de base de datos:

• Los cambios de índice son cambios de esquema. Si el repositorio tiene una herramienta de migraciones, agrega el índice allí. De lo contrario, propónlo con stage_migration, incluyendo los números medidos en la rationale.
• En PostgreSQL, usa CREATE INDEX CONCURRENTLY para cualquier tabla con tráfico y no lo envuelvas en una transacción.
• Una reescritura de consulta es un cambio de código: edita el código que la emite y menciona el resultado del benchmark en tu resumen.