Почему добавление OFFSET к запросу clickhouse увеличивает время выполнения? - PullRequest
0 голосов
/ 12 марта 2020

У меня есть таблица с примерно 9 миллионами записей. Когда я пытаюсь выбрать записи с большим смещением (для разбивки на страницы), это увеличивает время выполнения до предельных значений. Или даже вызывает превышение пределов памяти и сбои.

Вот журналы для запроса с двумя различными значениями смещения.

SELECT * WHERE set_date> = '2019-10-11 11 : 05: 00 'И set_date <=' 2019-10-19 18:09:59 'ЗАКАЗАТЬ ПО ИДЕНТИФИКАТОРУ AS C ПРЕДЕЛ 1 <strong>СМЕЩЕНИЕ 30

<strong>Elapsed: 0.729 sec.</strong> Processed 9.92 million rows, 3.06 GB (13.61 million rows/s., 4.19 GB/s.) 
MemoryTracker: <strong>Peak memory usage</strong> (for query): 181.65 MiB.

ВЫБРАТЬ * ГДЕ set_date> = '2019-10-11 11:05:00' И set_date <= '2019-10-19 18:09:59' ЗАКАЗАТЬ ПО ИДЕНТИФИКАТОРУ AS C ПРЕДЕЛ 1 <strong>СМЕЩЕНИЕ 3000000

<strong>Elapsed: 6.301 sec.</strong> Processed 9.92 million rows, 3.06 GB (1.57 million rows/s., 485.35 MB/s.) 
MemoryTracker: <strong>Peak memory usage</strong> (for query): 5.89 GiB.

1 Ответ

0 голосов
/ 12 марта 2020

Все базы данных, включая CH, реализуют OFFSET одинаково. Они просто читают все строки и пропускают OFFSET в наборе результатов. Нет никакой оптимизации, чтобы подняться прямо в OFFSET 3000000.

https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow/

попробуйте отключить optimize_read_in_order, чтобы исправить использование памяти

SELECT * 
WHERE set_date >= '2019-10-11 11:05:00' 
AND set_date <= '2019-10-19 18:09:59' 
ORDER BY id ASC LIMIT 1 OFFSET 3000000
setting optimize_read_in_order=0
...