Ребятушки, почему разница во времени запроса так велика?

SELECT count()
FROM 
(
    SELECT symbol
    FROM trades
    PREWHERE type = 'SPOT'
    GROUP BY symbol
)

┌─count()─┐
│     764 │
└─────────┘

1 rows in set. Elapsed: 27.835 sec. Processed 3.29 billion rows, 7.63 GB (117.97 million rows/s., 273.90 MB/s.)

против

SELECT uniq(symbol)
FROM trades
PREWHERE type = 'SPOT'

┌─uniq(symbol)─┐
│          764 │
└──────────────┘

1 rows in set. Elapsed: 342.113 sec. Processed 3.29 billion rows, 7.63 GB (9.60 million rows/s., 22.30 MB/s.)

Ребятушки, почему разница во времени запроса так велика?

SELECT count()
FROM 
(
    SELECT symbol
    FROM trades
    PREWHERE type = 'SPOT'
    GROUP BY symbol
)

┌─count()─┐
│     764 │
└─────────┘

1 rows in set. Elapsed: 27.835 sec. Processed 3.29 billion rows, 7.63 GB (117.97 million rows/s., 273.90 MB/s.)

против

SELECT uniq(symbol)
FROM trades
PREWHERE type = 'SPOT'

┌─uniq(symbol)─┐
│          764 │
└──────────────┘

1 rows in set. Elapsed: 342.113 sec. Processed 3.29 billion rows, 7.63 GB (9.60 million rows/s., 22.30 MB/s.)

потому, что uniq по дефолту использует вероятностную функцию
Для точного результата есть uniqExact()
еще можешь попробовать count(DISTINCT symbol), но он преобразуется в uniqExact

потому, что uniq по дефолту использует вероятностную функцию
Для точного результата есть uniqExact()
еще можешь попробовать count(DISTINCT symbol), но он преобразуется в uniqExact

так должна быть быстрее?

Там же по дефолту uniqExact вроде стоит

uniqExact() работает так же медленно

а если optimize_aggregation_in_order=1 и первый запрос
а если optimize_aggregation_in_order=0 и первый запрос

29.093 sec и 76.725 sec. соответственно. Второй раз вообще 22.456 sec. и 142.919 sec.

чего-то я не понял, optimize_aggregation_in_order=0 по дефолту

ну и на нормальном железе все эти запросы будут выполняться за 0.05 сек.

даже без SSD?

она существует только проверки на дубли

Доброго. Только знакомлюсь с КХ. Необходима реализация хранения уникальных значений. Сейчас есть табличка MySql на 177 миллионов значений, id: BIGINT и value: VARCHAR(255), ее пополняю новыми и через ON DUPLICATE KEY проверяю по ключу индекса на существование, в случае совпадения пропускаю - поэтому из одного запроса на 5000 записей в табличку попадают только 3555 к примеру. MySql действительно сейчас все тяжелей и дольше начинает с ней работать. Решит ли эту задачу КХ? Как можно реализовать ее пополнение проверяя наличие совпадений в табличке?