Skip to main content
Muestra el plan de ejecución de una sentencia.
Sintaxis:
Ejemplo:

​
Tipos de EXPLAIN

  • AST — Árbol de sintaxis abstracta.
  • SYNTAX — Texto de la consulta tras las optimizaciones a nivel de AST.
  • QUERY TREE — Árbol de consulta tras las optimizaciones a nivel de Query Tree.
  • PLAN — Plan de ejecución de la consulta.
  • PIPELINE — Pipeline de ejecución de la consulta.

​
EXPLAIN AST

Muestra el AST de la consulta. Admite todo tipo de consultas, no solo SELECT. Configuración:
  • graph – Imprime el AST como un grafo descrito en el lenguaje de descripción de grafos DOT. Valor predeterminado: 0.
Ejemplos:

​
EXPLAIN SYNTAX

Muestra el árbol de sintaxis abstracta (AST) de una consulta tras el análisis sintáctico. Esto se hace analizando la consulta, construyendo el AST y el árbol de consulta, ejecutando opcionalmente el analizador de consultas y las pasadas de optimización, y convirtiendo después el árbol de consulta de nuevo en el AST de la consulta. Configuración:
  • oneline – Imprime la consulta en una sola línea. Valor predeterminado: 0.
  • run_query_tree_passes – Ejecuta las pasadas del árbol de consulta antes de volcar el árbol de consulta. Valor predeterminado: 0.
  • query_tree_passes – Si se establece run_query_tree_passes, especifica cuántas pasadas se ejecutan. Si no se especifica query_tree_passes, se ejecutan todas las pasadas.
Ejemplos:
Query
Response
Con run_query_tree_passes:
Query
Response

​
EXPLAIN QUERY TREE

Configuración:
  • run_passes — Ejecuta todas las pasadas del árbol de consulta antes de volcarlo. Valor predeterminado: 1.
  • dump_passes — Vuelca información sobre las pasadas utilizadas antes de volcar el árbol de consulta. Valor predeterminado: 0.
  • passes — Especifica cuántas pasadas ejecutar. Si se establece en -1, ejecuta todas las pasadas. Valor predeterminado: -1.
  • dump_tree — Muestra el árbol de consulta. Valor predeterminado: 1.
  • dump_ast — Muestra el AST de la consulta generado a partir del árbol de consulta. Valor predeterminado: 0.
Ejemplo:

​
EXPLAIN PLAN

Muestra los pasos del plan de consulta. Configuración:
  • optimize — Controla si las optimizaciones del plan de consulta se aplican antes de mostrar el plan. Predeterminado: 1.
  • header — Imprime el encabezado de salida del paso. Predeterminado: 0.
  • description — Imprime la descripción del paso. Predeterminado: 1.
  • indexes — Muestra los índices utilizados, el número de partes filtradas y el número de gránulos filtrados para cada índice aplicado. Predeterminado: 0. Compatible con tablas MergeTree. A partir de ClickHouse >= v25.9, esta sentencia solo muestra una salida adecuada cuando se usa con SETTINGS use_query_condition_cache = 0, use_skip_indexes_on_data_read = 0.
  • projections — Muestra todas las proyecciones analizadas y su efecto en el filtrado a nivel de parte según las condiciones de la clave primaria de la proyección. Para cada proyección, esta sección incluye estadísticas como el número de partes, filas, marcas y rangos evaluados con la clave primaria de la proyección. También muestra cuántas partes de datos se omitieron debido a este filtrado, sin leer de la propia proyección. Si una proyección se usó realmente para la lectura o solo se analizó para el filtrado puede determinarse mediante el campo description. Predeterminado: 0. Compatible con tablas MergeTree.
  • actions — Imprime información detallada sobre las acciones del paso. Predeterminado: 1.
  • sorting — Imprime la descripción de ordenación de cada paso del plan que produce una salida ordenada. Predeterminado: 0.
  • keep_logical_steps — Conserva los pasos lógicos del plan para joins en lugar de convertirlos en implementaciones físicas de join. Predeterminado: 0.
  • json — Imprime los pasos del plan de consulta como una fila en formato JSON. Predeterminado: 0. Se recomienda usar el formato TabSeparatedRaw (TSVRaw) para evitar escapes innecesarios.
  • input_headers — Imprime los encabezados de entrada del paso. Predeterminado: 0. Principalmente útil solo para desarrolladores al depurar problemas relacionados con discrepancias entre los encabezados de entrada y salida.
  • column_structure — Imprime también la estructura de las columnas en los encabezados, además de su nombre y tipo. Predeterminado: 0. Principalmente útil solo para desarrolladores al depurar problemas relacionados con discrepancias entre los encabezados de entrada y salida.
  • distributed — Muestra los planes de consulta ejecutados en nodos remotos para tablas distribuidas o réplicas paralelas. No compatible con json. Predeterminado: 0.
  • compact — Cuando está habilitado, oculta del plan los pasos de expresión y la información detallada de las acciones (entradas, funciones, alias y posiciones de salida). Solo tiene efecto cuando actions = 1. Predeterminado: 1.
  • pretty — Imprime el árbol del plan usando caracteres de dibujo de líneas (├──, └──, │) en lugar de sangría para visualizar la jerarquía. También muestra en línea las propiedades del paso de join. Predeterminado: 1.
De forma predeterminada, explain_query_plan_default = 'pretty', por lo que actions, compact y pretty se inicializan en 1 y el plan se representa en la forma compacta, visualmente estructurada y anotada con acciones. Especificar cualquiera de estas opciones explícitamente en la sentencia EXPLAIN (por ejemplo, EXPLAIN actions = 0, compact = 0, pretty = 0 SELECT ...) siempre sobrescribe el valor predeterminado.Antes de ClickHouse 26.7, los valores predeterminados de actions, compact y pretty eran 0. Aún puede obtener esa salida configurando explain_query_plan_default = 'legacy' (globalmente o en SETTINGS por consulta), o configurando compatibility en cualquier versión anterior a 26.7.Las opciones json y distributed no habilitan los valores predeterminados de pretty (actions, compact y pretty), incluso cuando explain_query_plan_default = 'pretty'. Para incluir detalles de las acciones en su salida, configure actions = 1 manualmente.
Ejemplo:
No se admite la estimación del costo de los pasos ni de la consulta.
Cuando json = 1, el plan de consulta se representa en formato JSON. Cada nodo es un diccionario que siempre tiene las claves Node Type, Node Id y Plans. Node Type es una cadena con el nombre del paso, y Node Id es un identificador único del paso (el nombre del paso con un sufijo numérico, p. ej. Union_10). Plans es un array con descripciones de pasos secundarios. Pueden añadirse otras claves opcionales según el tipo de nodo y la configuración. Ejemplo:
Con description = 1, se añade la clave Description al paso:
Con header = 1, la clave Header se agrega al paso como un array de columnas. Ejemplo:
Con indexes = 1, se añade la clave Indexes. Contiene un array de los índices usados. Cada índice se describe como JSON con la clave Type (una cadena Partition Min-Max, Partition, Statistics, PrimaryKey o Skip) y claves opcionales:
  • Name — El nombre del índice (actualmente solo se usa para índices Skip).
  • Keys — El array de columnas que usa el índice.
  • Condition — La condición usada.
  • Description — La descripción del índice (actualmente solo se usa para índices Skip).
  • Parts — El número de partes después/antes de aplicar el índice.
  • Granules — El número de gránulos después/antes de aplicar el índice.
  • Ranges — El número de rangos de gránulos después de aplicar el índice.
Ejemplo:
Con projections = 1, se añade la clave Projections. Contiene un array de proyecciones analizadas. Cada proyección se describe como JSON con las siguientes claves:
  • Name — El nombre de la proyección.
  • Condition — La condición de la clave primaria usada por la proyección.
  • Description — La descripción de cómo se usa la proyección (p. ej., filtrado a nivel de partes).
  • Selected Parts — Número de partes seleccionadas por la proyección.
  • Selected Marks — Número de marcas seleccionadas.
  • Selected Ranges — Número de rangos seleccionados.
  • Selected Rows — Número de filas seleccionadas.
  • Filtered Parts — Número de partes omitidas debido al filtrado a nivel de partes.
Ejemplo:
Con actions = 1, las claves añadidas dependen del tipo de paso. Ejemplo:
Con compact = 0 y actions = 1, se pueden ver los pasos Expression junto con información detallada sobre las expresiones:
Con distributed = 1, la salida incluye no solo el plan de consulta local, sino también los planes de consulta que se ejecutarán en los nodos remotos. Esto resulta útil para analizar y depurar consultas distribuidas.
distributed se representa solo en la forma legacy (no pretty), porque la salida pretty no integra los planes de los segmentos remotos en el árbol del plan. Por este motivo, habilitar distributed desactiva automáticamente los valores predeterminados de pretty (actions, compact y pretty), independientemente de explain_query_plan_default. Aun así, puede establecer actions=1 manualmente. La opción distributed tampoco se admite junto con json.
Ejemplo con tabla distribuida:
Ejemplo con réplicas paralelas:
En ambos ejemplos, el plan de consulta muestra el flujo de ejecución completo, incluidos los pasos locales y remotos. Con pretty = 1, el árbol del plan se muestra con caracteres de dibujo de líneas en lugar de sangría, y se muestra información adicional para los pasos clave:
  • Las columnas de salida de la consulta se imprimen en la parte superior del plan.
  • Las expresiones en filtros, claves de agregación, descripciones de ordenación y funciones de ventana se muestran en una notación legible para humanos similar a SQL (por ejemplo, a + 1 > 5 en lugar de greater(plus(a, 1), 5)). Los prefijos internos de los identificadores de columna (como __table1.) se eliminan para mayor claridad.
  • Los pasos de origen (como ReadFromMergeTree) muestran sus columnas de salida.
  • Los pasos de filtro muestran la condición de filtro en notación SQL. Cuando hay filtros de join en tiempo de ejecución, se muestran por separado.
  • Los pasos de agregación muestran las claves y las funciones de agregación con sus argumentos (por ejemplo, sum(c), count()).
  • Los conjuntos IN de literales de tupla muestran sus valores (truncados para conjuntos grandes), los conjuntos basados en subconsultas se etiquetan como subquery1, subquery2, etc., y los conjuntos de tablas con motor Set muestran el nombre de la tabla.
  • Los pasos de join muestran la relación de join mediante notación matemática, el número estimado de filas del resultado, y qué columnas de salida provienen del lado izquierdo frente al derecho. Se usan los siguientes símbolos para representar distintos tipos de JOIN:
Por ejemplo, t1 ⟕ t2 significa un JOIN izquierdo entre las tablas t1 y t2. El número entre corchetes después del nombre de la tabla (p. ej., t1[100]) indica el número estimado de filas cuando hay estadísticas de tabla disponibles. La opción pretty funciona bien junto con compact = 1, que oculta los pasos Expression y la información detallada de las acciones, lo que hace que el plan sea más fácil de leer. Un ejemplo detallado con JOIN:

​
EXPLAIN PIPELINE

Configuración:
  • header — Muestra el encabezado de cada puerto de salida. Valor predeterminado: 0.
  • graph — Muestra un grafo descrito en el lenguaje de descripción de grafos DOT. Valor predeterminado: 0.
  • compact — Muestra el grafo en modo compacto si la configuración graph está habilitada. Valor predeterminado: 1.
  • compact_repeated_processor_chains — Compacta las cadenas repetidas de procesadores adyacentes en la salida de texto mostrando una sola copia de la cadena junto con el número de repeticiones. Esto puede facilitar la lectura de las canalizaciones paralelas cuando la misma cadena aparece muchas veces, por ejemplo, en joins. No afecta a la salida del grafo. Valor predeterminado: 0.
Cuando compact=0 y graph=1, los nombres de los procesadores contendrán un sufijo adicional con un identificador único de procesador. Ejemplo:

​
EXPLAIN ESTIMATE

Muestra el número estimado de filas, marcas y partes que se leerán de las tablas al procesar la consulta. Funciona con tablas de la familia MergeTree. Ejemplo Crear una tabla:
Query
Query
Response

​
EXPLAIN WHATIF

Estima el beneficio que tendría un índice de omisión hipotético en una consulta SELECT, sin materializar el índice en disco. Defina uno o más candidatos con CREATE HYPOTHETICAL INDEX y luego ejecute EXPLAIN WHATIF SELECT ... para ver, para cada candidato, si aplica, las marcas estimadas leídas, los bytes estimados y la tasa de omisión. Sintaxis
Configuración
  • empirical — 1 (predeterminado) ejecuta el índice en memoria sobre los gránulos descartados según la línea base para medir la tasa de descarte (un límite superior). 0 omite ese paso. En cualquier caso, si empirical no produce un resultado (porque está deshabilitado o porque el índice no puede evaluarse en memoria), el estimador recurre a las estadísticas de columna y, por último, a un resumen únicamente de aplicabilidad si ninguna de las dos está disponible.
Salida
  • source — cómo se generó la estimación.
    • empirical: construyó el índice en memoria sobre los gránulos podados por la línea base y contó los gránulos que el índice omitiría. Este es un límite superior; consulta las limitaciones en CREATE HYPOTHETICAL INDEX.
    • statistical: se deriva de las estadísticas de columnas. Se usa cuando empirical está deshabilitado (empirical = 0) o cuando empirical no pudo producir un resultado, y hay estadísticas de columnas definidas en las columnas relevantes.
    • applicability_only: el índice es aplicable al predicado, pero ni la estimación empirical ni la statistical produjeron un resultado (p. ej., empirical = 0 y no hay estadísticas de columnas definidas). Informa skip_ratio: 0.0% como límite conservador.
  • sampled_parts / sampled_marks — <baseline-pruned> / <total in the table>. Muestra qué fracción de la tabla quedó tras la poda por PK, partición e índices existentes; es decir, la entrada del índice hipotético.
  • est_bytes — una estimación de los bytes leídos, derivada del tamaño medio de fila de la tabla, por lo que es aproximada y varía según el almacenamiento y la compresión. La línea de base aparece solo cuando la consulta lee filas; la línea por candidato, solo cuando se conoce la estimación de bytes de la línea de base.
La configuración se escribe en línea entre WHATIF y SELECT; no hay palabra clave SETTINGS (esto coincide con cómo otras variantes de EXPLAIN aceptan sus opciones). Si no hay índices hipotéticos definidos para la tabla, EXPLAIN WHATIF informa status: not_applicable con una sugerencia para crear uno. Ejemplo empírico
El minmax hipotético podaría de 100 marcas a 1 — skip_ratio: 99.0%. (est_bytes es una estimación basada en el tamaño promedio de la fila, por lo que la cifra exacta puede variar.) Ejemplo estadístico Las estadísticas de columna están desactivadas de forma predeterminada. Para usar la ruta statistical, defínalas primero en las columnas correspondientes y espere a que finalice la mutación de materialización:
Luego, deshabilite el método empírico para que el estimador vuelva a usar las estadísticas de columna:
El número proviene de la selectividad de las estadísticas de columna para b < 10 (aproximadamente 10 filas de 10000) y se muestra como un límite superior de skip_ratio. No hay sampled_parts / sampled_marks: no se leyó ningún dato. Si ninguna de las dos vías está disponible (p. ej., empirical = 0 y no hay estadísticas de columna definidas), el estimador informa source: applicability_only y un skip_ratio: 0.0% conservador.

​
EXPLAIN TABLE OVERRIDE

Muestra el resultado de una sobrescritura de tabla aplicada al esquema de una tabla a la que se accede mediante una función de tabla. También realiza ciertas validaciones y genera una excepción si la sobrescritura hubiera provocado algún tipo de fallo. Ejemplo Suponga que tiene una tabla MySQL remota como esta:
Query
Query
Response
La validación aún no es exhaustiva, por lo que una consulta correcta no garantiza que la sobrescritura no vaya a causar problemas.
Última modificación el 1 de julio de 2026