Ануко скажите мне иксперты - какие вы видите риски если таблицы с кучей (heap) и имеющимся первичным ключем некластерным изменить - ебануть кучу кхуям и ПК сделать кластерным с тем же именем?

ну в диасофт почти весь код хуячит с хинтами with(index=index_name) - понятно что изменять имена индексов нельзя...

я щас чота делаю на ряде таблиц это - вроде ничего не предвещает бури...

некоторые таблица ужимаются аж пиздец например была табличка 508 строк reserved = data = 17gb
после изменения ПК на кластерный индекс стала весить 210mb... ну то есть стопицот лет никто ее не ребилдил всмысле heap... а стандартный ребилд не работал здесь... понятны плюсы - ребилд индекса ночами да и отсутствие forwarding pointer...

но наверняка бл какие то риски могут возникнуть?

из плюсов... я смотрю статистику использования индексов... ну и на куче где куча лукапов... то есть идет поиск по некластерному индексу (таблица куча + один ПК), и на таблице лукапы )))).
понятно что если заменить индекс на ровно такой же но кластерный - будет некая быстрая оптимизация не вникая особо в дебри кода.

Куча имеет преимущество только в одном - вставки без доп индексов. Как только пошли апдейты, удаления - куча превращается во фрагментированное говно

если кластерный индекс монотонно возрастающий типа int/bigint identity то не быстрее - вашпе пох - одинаково

в случае если делается ребилд таблицы...