Se uma tabela de banco de dados tiver 3 TB de tamanho e a velocidade de leitura for de 10 mbyte/s. Isso significa que 83 horas são necessárias para criar um novo índice?

É mais complicado do que isso. Quando você cria um índice (B-Tree), não apenas todos os dados para os quais o índice se destina, precisam ser lidos, alguns deles são lidos várias vezes à medida que são convertidos em uma B-Tree. Isso ocorre porque o SQL Server usa especificamente uma árvore B balanceada . Não tenho certeza se há alguma documentação sobre o algoritmo exato da Microsoft, mas este artigo discute uma maneira prática de converter um conjunto desordenado de dados em uma árvore B balanceada , que é um processo de duas etapas.

Além disso, se ocorrer alguma reclassificação durante a criação, isso também adicionará mais tempo à criação do índice. Um exemplo em que isso pode acontecer é se você estiver fazendo uma operação de compilação de índice online no SQL Server e novas linhas forem adicionadas à tabela durante a operação.

Como outros apontaram, 10 MB/s é um disco rígido suspeitosamente lento. Para referência, atualmente o armazenamento EBS mais lento na AWS tem uma média de cerca de 65 MB/s (geração anterior - entre 40-90 MiB/s) e não acho que os discos rígidos regulares tenham sido tão lentos quanto 10 MB/s desde os anos 90 ( embora eu não tenha encontrado nenhuma fonte para isso).

Dependendo da finalidade do seu índice, talvez um índice filtrado seja útil para você, se você não precisar indexar todas as linhas. Teoricamente, deve criar mais rápido, pois indexa apenas um subconjunto dos dados com base no filtro aplicado na definição. Isso é útil nos casos em que você consulta principalmente apenas um subconjunto dos dados, por exemplo, tudo desde 2015 ou qualquer critério estático que você deseja definir no filtro. Também economiza espaço, pois menos dados estão sendo indexados. Mas também esteja ciente das limitações, que Brent Ozar discute em O que você pode (e não pode) fazer com índices filtrados .