Ну тут смотря, какие еще поля участвуют в индексе.
Возможны разные комбинации, допустим
ORDER BY (key1,toDate(timestamp),key2,timestamp)

Ну то есть, в конце составного индекса допустимо, первым судя по всему не имеет смысл ts юзать

Первым в 99% случаях не стоит делать таймстамп в индексе.

А можно прояснить этот момент?
Т.е. если есть условная таблица  

    CREATE TABLE
    (
       created DateTime('UTC') DEFAULT now(),
       name LowCardinality(String),
       value Float64
       ...
    )
    PARTITION BY toStartOfDay(created)
    PRIMARY KEY(created,name)
    ORDER BY (created,name)
    

   То не нужно включать created в PK даже если выборки всегда идут по диапазону времени?

    CREATE TABLE
    (
       created DateTime('UTC') DEFAULT now(),
       name LowCardinality(String),
       value Float64
       ...
    )
    PARTITION BY toStartOfDay(created)
    PRIMARY KEY(created,name)
    ORDER BY (created,name)
    

Ну, тут дело в том, что обычно в запросах не только выборки по времени а допустим и по name. В таком случае обычно эффективнее отбросить сразу большое число записей по name и уже оставшееся отбрасывать дальше по времени.
Отдельный вопрос какой процент запросов обращается к данным меньше, чем за один день

Т.е. тогда не то, чтобы выкинуть created, а переместить его типа PK(name, created)?

Да, обычно timestamp находит себе место в конце ORDER BY

Отдельный вопрос какой процент запросов обращается к данным меньше, чем за один день
В моём случае скорее всего да, чаще запросы за сутки, реже за несколько дней.

Но я не связан с предыдущим вопрошающим если что)

Допустим в запросе нужно взять данные за час и для определенного name,
В твоем случае запрос просканирует все данные за час.
в случае name,timestamp запрос просканирует данные только для этого name и тут уже в зависимости от кол-ва записей просканирует записи за какой то диапазон времени.

Ну запрос за сутки, это как раз говорит в пользу name,timestamp.
Тк зачем тебе посекундная точность границ?) ты же запрашиваешь день.

Да. Ход мысли я кажется уловил )
Спасибо..

А тогда уточняющий. Это для PK или для ORDER BY нужно учитывать? Или для обоих эту логику применять?

PK и ORDER BY си есть одно и тоже(почти).
когда ты не задаешь PK, это означает PK=ORDER BY.
когда ты задаешь отдельный PK, который может быть только префиксом ORDER BY, это означает что clickhouse в памяти будет хранить именно PK и использует его для проверки условий WHERE, а данные на диске лежат в более полной сортировке ORDER BY.

Это нужно, что бы не раздувать объем занимаемым ключом в оперативной памяти, бывает что в сортировке лучше задать больше полей(допустим так сжатие будет лучше)

И как я понимаю идеально, чтобы в запросах всегда был ORDER BY совпадающий с заданным для таблицы?

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

Если вам сортировка в запросе не нужна, то никакой особой разницы вам не будет.

Хорошо. Стало понятнее. Спасибо ещё раз..

Там потихоньку вмерживают оптимизации для GROUP BY по ключу сортировки, но я особо не сталкивался насколько оно быстрее работает.

на самом деле PK ввели отличный от ORDER by чтобы была возможность в коллапсирующих движках урезать индекс и добавить возможность на лету добалять размерности т.е. был у вас SummingMT и у него был order by с1, с2, с3,........................................................... с38 и все это лежало в памяти и фильтровалось при where , PK позволил сделать PK с1, с2, с3 order by с1, с2, с3,........................................................... с38