unfilled

Стандарт предполагает использование COALESCE:

select COALESCE(price, 0) + COALESCE(price2, 0) + COALESCE(price3,0)  as suma from prices

Кластерный индекс лучше объявить уникальным (раз вы пишете, что TTfid уникальное. Оптимизатору всегда лучше предоставлять максимум информации.
Что касается индексов по конкретным столбцам - нужно видеть, какие конкретно запросы вы хотите оптимизировать. Без этого - гадание на кофейной гуще. Для запроса, где "join идет по полям: TTfid, TPid и TTowner" уникальный кластерный индекс по TTfld - то что доктор прописал.

Select ProcedureId, [3_1_explain_alert_system_and_boosters_required], [1_1_patient_blacklist_checked]
FROM 
(
    select ProcedureId, HtmlValue, TokenValue from ProcedureStepsDetails
) As Temp
PIVOT
(
    max([HtmlValue]) 
    FOR [TokenValue] In([3_1_explain_alert_system_and_boosters_required], [1_1_patient_blacklist_checked])
) As pt

а так?

case
when your_number in (1, 5, 9, 12, 14, 16, 19, 23, 27, 30, 32, 34) then 1
when your_number in (3, 6, 8, 10, 13, 17, 21, 24, 25, 29, 33, 36) then 2
when your_number in (2, 4, 7, 11, 15, 18, 20, 22, 26, 28, 31, 35) then 3
else null
end as line_num

Обрежьте журнал транзакций гигабайт до 5, установите приращение в 1 ГБ и не возвращайте БД в Full - вы всё равно не пользуетесь преимуществами полной модели восстановления. Оставьте в простой.
Deadlock'и у вас появляются из-за кривого кода 1С (ищите их документацию по причинам возникновения и избавлению от взаимоблокировок - её полно). Почему не возникали раньше? Возможно, потому что после "обрезки" ЖТ и переводе в полную модель восстановления, ЖТ снова начал расти и одна из кривых операций ждала завершения приращения, когда вторая кривая операция начала выполняться. Но это мой хрустальный шар только предполагает, вам и вашим одинэсникам виднее должно быть.

Вообще, эта штука (перестройка/реорганизиаця индексов) очень сильно переоценена. Пол Рэндал, например, открыто говорит, что трэшхолды (5 и 30% для реорганизации/перестройки) он просто взял из головы, потому что надо было что-то написать.
Ну и вот ещё хорошее свежее видео.
Вообще, по существу:
1. Пока индекс маленький, для его хранения SQL Server использует смешанные экстенты, соответственно, страницы индекса разбросаны по разным экстентам и реорганизация/перестройка никак, по сути, на него и не влияют. С маленькими индексами я вообще не заморачиваюсь.
2. Смотря что понимать под «деградированностью». В принципе, вкупе с page_count и avg_page_space_used_in_percent, avg_fragmentation_in_percent даёт вполне себе понятную картинку.
3. Так и выбирается. Если вы видите, что при вставке постоянно происходят page split'ы, то, возможно, имеет смысл сделать fill factor поменьше. Но при этом стоит помнить, что индекс сразу же раздуется в объёме, соответственно, поиск по нему будет осуществляться более медленно.

Я себе, пару недель назад, на ДР подарил Optimus Sol. В живую он выглядит намного лучше чем на фото. Доволен как слон.
Экран яркий (но на солнце надо яркость на полную выкручивать). Живет около 2-х дней в режиме — час плейер (подкасты по дороге на работу и с работы), минут 30-40 в день книга, минут 10-20 могу пошпилить во что-нибудь казуальное. Мобильные интернеты включены где-то с 12 до вечера, с 18 до 22-23 wi-fi (твиттер, почтой и IM-ами дома не пользуюсь). На ночь все интернеты выключаю, в режим самолета не перевожу, ибо ночью могут позвонить (сволочи :)).