Всем привет. У нас возникла проблема с легковесным удалением. Всё

хорошо работало, ничего не меняли. Раньше удаление занимало до 1-2 сек, но сейчас зависли уже на несколько часов. mutations_sync: 1, с базой ничего больше не происходит. Единственный инстанс базы (без репликации / шардирования) В мутациях и запросах висят только эти 6 удалений несколько часов без изменений. В мутациях выглядит вот так:
SELECT *вчера кстати не было
FROM system.mutations
WHERE is_done = 0
FORMAT Vertical

Query id: ff9f17e5-fb68-485b-9e6f-b1090abfe988

Row 1:
──────
database: olap
table: mandatory_matrix_fact
mutation_id: mutation_2672037.txt
command: UPDATE _row_exists = 0 WHERE (pharmacy = 28903) AND ((toUInt64(initiative) NOT IN (SELECT id FROM olap.mandatory_matrix_initiative)) OR ((insert_time < '2023-10-10 15:56:46') AND (toUInt64(initiative) IN (SELECT id FROM olap.mandatory_matrix_initiative WHERE quarter_date >= '2023-10-01'))))
create_time: 2023-10-10 15:56:46
block_numbers.partition_id: ['']
block_numbers.number: [2672037]
parts_to_do_names: ['all_2655293_2656555_52_2672035','all_2656557_2660066_101_2672035','all_2660068_2661867_69_2672035','all_2661869_2666237_42_2672035','all_2666240_2669074_42_2672035','all_2669076_2670560_29_2672035','all_2670562_2671448_29_2672035','all_2671450_2671819_33_2672035','all_2671821_2672034_20_2672035']
parts_to_do: 9
is_done: 0
latest_failed_part:
latest_fail_time: 1970-01-01 03:00:00
latest_fail_reason:
Если запрос поменять на select, то видно что строк вообще не должно быть удалено. Кто-то может подсказать как понять причину?

а в system.merges по это таблице идут мержи?

Ага SELECT * FROM system.merges FORMAT Vertical Query id: 221a72ba-fa67-4778-8ef3-1e9aab6b338d Row 1: ────── database: olap table: mandatory_matrix_fact elapsed: 0.188544956 progress: 0.037337360764132604 num_parts: 9 source_part_names: ['all_2655293_2656555_52_2672035','all_2656557_2660066_101_2672035','all_2660068_2661867_69_2672035','all_2661869_2666237_42_2672035','all_2666240_2669074_42_2672035','all_2669076_2670560_29_2672035','all_2670562_2671448_29_2672035','all_2671450_2671819_33_2672035','all_2671821_2672034_20_2672035'] result_part_name: all_2655293_2672034_102_2672035 source_part_paths: ['/var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2655293_2656555_52_2672035/','/var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2656557_2660066_101_2672035/','/var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2660068_2661867_69_2672035/','/var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2661869_2666237_42_2672035/','/var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2666240_2669074_42_2672035/','/var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2669076_2670560_29_2672035/','/var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2670562_2671448_29_2672035/','/var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2671450_2671819_33_2672035/','/var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2671821_2672034_20_2672035/'] result_part_path: /var/lib/clickhouse/store/b36/b368adca-c247-462a-b9bc-72643c1894a3/all_2655293_2672034_102_2672035/ partition_id: all is_mutation: 0 total_size_bytes_compressed: 137183811 total_size_marks: 1575 bytes_read_uncompressed: 69255168 rows_read: 4087808 bytes_written_uncompressed: 68026368 rows_written: 2845777 columns_written: 0 memory_usage: 30892373 thread_id: 1574814 merge_type: Regular merge_algorithm: Vertical 1 row in set. Elapsed: 0.002 sec.

по идентификаторам партов похоже что мерж как раз идет. А большая табличка по данным?

100 млн. Раньше с ней проблем не было. Раз в день мы так же делаем optimize table olap.mandatory_matrix_fact final занимает пару минут. Она ReplacingMergeTree.

3.4 гиб, 100M строк