andreymx,
Я не разработчик, поэтому возможно я не прав, но я это так вижу.
Таблица дата, имя, форма.
Я бы сделал в качестве ключа кластерного, дата и имя.
Если вам нужно шесть последних для конкретного юзера, по нему будет работать быстро.
Самые популярные за две недели. В принципе тоже должен быстро отработать. Здесь вы в where задаете имя и дату, сгруппируете по form_id и посчитаете кол-во, потом выведете 6 самых популярных.
В зависимости от запросов, возможно есть смысл добавить индекс просто по имени. Зависит от того насколько оно уникально и будут ли еще запросы кроме тех двух что назвали вы.

Akina,

Использовать ID пользователя как первый столбец в индексе, плохая идея.

Akina,

Будут постоянные сплиты, это раз.
И два, с чего это он не будет работать? В особенности для второго запроса, за последнии две недели?

Akina,

Тогда согласен.
Но причем тут фильтрация и сплиты? При таком индексе тогда FillFactor для него не по умолчанию делать.

Попробывал.
Создал таблицу, 10 лямов, 30 пользваотелей, 15 приложений, временной промежуток год.
SQL делает seek что в варианте с User первый, что с Date, планы одинаковые. Но с Date в три раза медленнее выполняется и делает в 10 раз больше лог. чтений.
Акина прав.
Но в таком случае тогда Fillfactor не по умолчанию нужно ставить.

Akina,

Понятно. Здесь зависит сколько данных есть в каком блоке. Если юзер работает уже пять лет и для него очень много записей, то возможно вариант сначала выбрать за две недели а потом по по юзеру будет быстрее, чем просто по юзеру.
Попробывал кстати вставку. Вставил 10 000 строк, 80 сплитов, по времени на процентов 20 где-то медленее. Поставил FillFactor 90, 2 сплита, скорость такая же как и без сплитов. Но у автора, опять же примерно, это кол-во вставок за час, а не за минуту.
Вывод. Как посоветовали вы и FillFactor 90.

Akina,

Попробывал, 30% строк все один пользватель, разницы практически нет, если за последнии две недели считай работал этот юзер.
Блин, я ужасно тупил.
Все логично. Если у нас индекс по юзеру, и мы ищем за последнии две недели, sql точно также смотрит промежуточный уровень, данные сначала идут по юзеру, потом дате, он смотрит на какой странице начинаются эти последнии две недели, так как второй столбец тоже есть в промежуточном уровне, и начинает оттуда читать. Он не сканит все страницы для юзера (я почему то думал что он сделает именно это) Итог 140 чтений.
Если же дата первая... Я начала добавлять данные за последнии две недели для разных пользователей, чем больше добавлял, тем больше было чтений, и это логично. В промежуточном уровне указана минимальная дате на странице и связаный с ней юзер, так как наш юзер "раскидан" по всем страницам, sql должен прочитать все данные за последнии две недели.
Вобщем я ошибался, спасибо :)