> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Lecciones: el problema de Too many parts

> Soluciones y prevención de Too many parts

*Esta guía forma parte de una recopilación de hallazgos surgidos de encuentros de la comunidad. Para conocer más soluciones prácticas e ideas basadas en casos reales, puedes [explorar por problema específico](/docs/es/resources/support-center/tips-and-tricks/community-wisdom).*
*¿Necesitas más consejos para optimizar el rendimiento? Consulta la guía de ideas de la comunidad sobre [Optimización del rendimiento](/docs/es/resources/support-center/tips-and-tricks/performance-optimization).*

<div id="understanding-the-problem">
  ## Comprender el problema
</div>

ClickHouse mostrará un error de "Too many parts" para evitar una degradación grave del rendimiento. Las partes pequeñas causan varios problemas: peor rendimiento de las consultas al tener que leer y fusionar más archivos durante su ejecución, mayor uso de memoria porque cada parte requiere metadatos en memoria, menor eficiencia de compresión porque los bloques de datos más pequeños se comprimen peor, mayor sobrecarga de E/S debido a un mayor número de descriptores de archivo y operaciones de `seek`, y merges en segundo plano más lentos, lo que da más trabajo al planificador de merges.

**Documentación relacionada**

* [Motor MergeTree](/docs/es/reference/engines/table-engines/mergetree-family/mergetree)
* [Partes](/docs/es/concepts/core-concepts/parts)
* [Tabla del sistema Parts](/docs/es/reference/system-tables/parts)

<div id="recognize-parts-problem">
  ## Detecte el problema a tiempo
</div>

Esta consulta supervisa la fragmentación de las tablas analizando el número y el tamaño de las partes en todas las tablas activas. Identifica las tablas con un número excesivo de partes o con partes demasiado pequeñas que pueden requerir optimización de merge. Úsela con regularidad para detectar problemas de fragmentación antes de que afecten al rendimiento de las consultas.

```sql runnable editable theme={null}
-- Desafío: Reemplaza con los nombres reales de tu base de datos y tabla para uso en producción
-- Experimento: Ajusta los umbrales de conteo de partes (1000, 500, 100) según tu sistema
SELECT 
    database,
    table,
    count() as total_parts,
    sum(rows) as total_rows,
    round(avg(rows), 0) as avg_rows_per_part,
    min(rows) as min_rows_per_part,
    max(rows) as max_rows_per_part,
    round(sum(bytes_on_disk) / 1024 / 1024, 2) as total_size_mb,
    CASE 
        WHEN count() > 1000 THEN 'CRITICAL - Too many parts (>1000)'
        WHEN count() > 500 THEN 'WARNING - Many parts (>500)'
        WHEN count() > 100 THEN 'CAUTION - Getting many parts (>100)'
        ELSE 'OK - Reasonable part count'
    END as parts_assessment,
    CASE 
        WHEN avg(rows) < 1000 THEN 'POOR - Very small parts'
        WHEN avg(rows) < 10000 THEN 'FAIR - Small parts'
        WHEN avg(rows) < 100000 THEN 'GOOD - Medium parts'
        ELSE 'EXCELLENT - Large parts'
    END as part_size_assessment
FROM system.parts
WHERE active = 1
  AND database NOT IN ('system', 'information_schema')
GROUP BY database, table
ORDER BY total_parts DESC
LIMIT 20;
```

<div id="video-sources">
  ## Fuentes de video
</div>

* [INSERTS asíncronos rápidos, concurrentes y consistentes en ClickHouse](https://www.youtube.com/watch?v=AsMPEfN5QtM) - Un miembro del equipo de ClickHouse explica los inserts asíncronos y el problema de «Too many parts»
* [ClickHouse en producción a escala](https://www.youtube.com/watch?v=liTgGiTuhJE) - Estrategias reales de procesamiento por lotes en plataformas de observabilidad