datahora2(0) vs datahora2(2)

O tamanho de dateTime2(0), dateTime2(1), dateTime2(2), dateTime2(3) usa a mesma quantidade de armazenamento. (6 bytes)

Estaria correto ao dizer que poderia muito bem ir com dateTime2(3) e obter o benefício da precisão sem nenhum custo adicional de tamanho.

Não, você interpretou mal a documentação. Observe que o documento indica o tamanho de armazenamento de 6 bytes para precisões menores que 3 (ênfase minha). Portanto, uma precisão igual a 3 exigirá 7 bytes.

Se você não se importa com milissegundos, datetime2(0)seria o tipo de dados e a precisão adequados. A melhor prática é especificar o tipo de dados adequado e a precisão com base nos dados armazenados, pois isso fornecerá armazenamento e eficiência ideais de forma inerente. Dito isso, não esperaria um impacto significativo no desempenho com base na precisão datetime2 especificada, desde que o tamanho do armazenamento seja o mesmo, mas não testei especificamente isso sozinho.

Os requisitos do aplicativo ditarão o que deve ser armazenado no banco de dados quando uma maior precisão estiver disponível na fonte. Por exemplo, para um tempo de entrada de pedido proveniente de SYSDATETIME(), os usuários podem não querer uma precisão de 100 nanossegundos. Mais uma vez, escolha o tipo de dados e a precisão para o novo desenvolvimento de acordo com os requisitos e, em geral, você obterá o desempenho ideal sem pensar muito:

• data - você não precisa de tempo
• smalldatetime - você não precisa de segundos
• datetime2(0) - você não precisa de segundos fracionários
• datetime2(1-7) - você precisa de segundos fracionários da precisão especificada
• datetimeoffset(0-7) - você precisa de data e hora com reconhecimento de fuso horário
• time(0-7) - você precisa apenas de tempo (sem data) com segundos fracionários da precisão especificada

Embora datetime2 seja mais apropriado para novos desenvolvimentos conforme listado acima, às vezes pode ser necessário usar datetime (precisão fixa 3 com precisão de 1/300 segundos fracionários) em vez de compatibilidade com aplicativos de data e hora herdados, evitando assim conversões implícitas e comportamento de comparação inesperado, mas em a despesa de precisão de fração de segundo e maior armazenamento.

Considere que armazenar uma precisão maior do que a necessária também pode ter um custo de desenvolvimento. Se alguém armazenar um componente de tempo com segundos fracionários quando apenas a precisão do segundo inteiro for necessária, as consultas ainda precisarão considerar os segundos fracionários para retornar os resultados corretos. Por exemplo, com um aplicativo em que o usuário seleciona um intervalo de tempo por meio de uma interface do usuário que permite apenas segundos inteiros, o código do aplicativo precisaria contabilizar os segundos fracionários no valor do intervalo de tempo final e ajustar o valor fornecido pelo usuário de acordo (por exemplo, WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'ou WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). Isso adicionará complexidade ao código.