ClickHouse는 심각한 성능 저하를 방지하기 위해 “Too many parts” 오류를 발생시킵니다. 작은 파트는 여러 문제를 유발합니다. 쿼리 시 더 많은 파일을 읽고 머지해야 하므로 쿼리 성능이 저하되고, 각 파트의 메타데이터를 메모리에 유지해야 하므로 메모리 사용량이 증가합니다. 또한 더 작은 데이터 블록은 압축 효율이 낮고, 파일 핸들과 seek 작업이 늘어나 I/O 오버헤드가 커지며, 백그라운드 머지가 느려져 머지 스케줄러의 작업 부담도 증가합니다.관련 문서
이 쿼리는 모든 활성 테이블의 파트 수와 크기를 분석해 테이블 단편화를 모니터링합니다. 파트가 과도하게 많거나 지나치게 작아 머지 최적화가 필요할 수 있는 테이블을 식별합니다. 단편화 문제가 쿼리 성능에 영향을 미치기 전에 발견할 수 있도록 이 쿼리를 정기적으로 사용하십시오.
runnable editable
-- 챌린지: 실제 데이터베이스 및 테이블 이름으로 대체하여 프로덕션 환경에서 사용하십시오-- 실험: 시스템 환경에 맞게 파트 수 임계값(1000, 500, 100)을 조정하십시오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_assessmentFROM system.partsWHERE active = 1 AND database NOT IN ('system', 'information_schema')GROUP BY database, tableORDER BY total_parts DESCLIMIT 20;