Комментарии 2
Ну а через system.query_log Вы не пробовали смотреть на свои запросы? В первом запросе с низкой кардинальностью у вас в поле ВозвращеноСтрок условно будет 1000, а в другом 1000000. То есть утверждение про карлинальность низкую, что она для гроуп бай хороша - ну она вытекает просто из метрики возвращено строк и что Вы трафик нагружаете, и что заставляете КХ гонять всю таблицу через ЦПУ и Ram. Повесить фильтр на Ваш запрос, и даже при высокой кардинальности в таблице как таковой, если фильтр отсечет гранулы как надо и достанет 1000 строк, на гроуп буй по 1000 строк расчёт кардинальности ничего не даст. Там что 1000 строк вернуть, что 1. Разница будет в микросекундах. Потому что обычно 1000 строк помещается в стандартный размер гранулы.
Вы привели хороший и наглядный пример анализа одного конкретного запроса вручную после его выполнения. Действительно, если запрос один, и он оптимизируется вручную, есть возможность несколько раз его выполнить, посмотреть план выполнения запроса, логи и т.д. — кардинальности не нужны, но это частная задача.
В движке Visiology решается общая задача — оптимизация произвольного (не конкретного) SQL запроса до его выполнения (не после), и без дополнительных запросов к СУБД (например, для подсчета уникальных значений комбинации полей одной таблицы), и оптимизация «с первой попытки» (не после просмотра логов и выполнения, возможно, неоптимального запроса), в таком случае актуальны кардинальности.
Кардинальность при оптимизации DAX запросов в ClickHouse