Ммм. Так...
Ни в коем случае не используй второй вариант - он слишком негибок. Представь себе, что потребуется объединять датчики в группы по некоему критерию. И что, будешь писать отдельный селект на каждый случай, или будешь извращаться с Dynamic SQL?
Насчет времени вставки - это индексы мутят, как пить дать (ох, проклятый сушняк...

). Давай прикинем, по какому критерию у тебя чаще всего идет поиск:
1. CheckDate - однозначно. В принципе, я наверное перестарался, сказав, что это должен быть кластерный индекс, но я не вижу больше ни одного кандидата на эту роль. А сортировать тебе надо именно по времени, верно? Кроме того, вставка задним числом у тебя невозможна в силу бизнес-логики. Значит, оставляем его как есть (Primary Key Clustered), только ставим ему Fill Factor = 50. Ну или меньше, вплоть до 10, если поможет, конечно. Уберешь кластерность - появятся доп. расходы на сортировку;
2. ParameterId - говоришь, их у тебя 723... Попробуй выставить обычный индекс, но филл фактор = 5, более того, попробуй также поставить галку PAD Index - эта опция заставляет оставлять свободное место не только в конечных страницах индекса, но и в промежуточных. Не исключено, что это как раз твой случай. Одна только проблема - когда ты дойдешь до исчерпания свободного места с страницах индекса, первый же инсерт у тебя столько займет времени... Страшно подумать. Но это уже вопросы администрирования, и здесь поможет грамотный Maintenance Plan с DBCC DBREINDEX / INDEXDEFRAG...
3. Кавер-индекс на все остальные поля. Филл-фактор... ну, я бы попробовал оставить дефолтный 0 - пусть сиквел сам думает, у него процессоров больше, чем у меня голов

. Либо вообще его дропни и посмотри, сильно ли изменится скорость инсертов/селектов.
Вот что меня еще интересует: у тебя приоритет на скорость вставки записей или на скорость получения отчета? Если на первое, то пункт 3 я бы вообще удалил. Если же на второе, то можно немного закрутить фил-факторы в большую сторону. Но это уже детали, конечно...