Limites no número de linhas em uma tabela do SQL Server

Além de todos os itens acima, que são ótimas recomendações, eu pensei que daria um pouco mais de contexto no ponto de índice/desempenho.

Como mencionado acima, não é possível fornecer um número de desempenho, pois dependendo da qualidade e do número de seus índices, o desempenho será diferente. Também depende das operações que você deseja otimizar. Você precisa otimizar inserções? ou você está mais preocupado com a resposta da consulta?

Se você está realmente preocupado com a velocidade de inserção, o particionamento, bem como uma consideração de índice muito cuidadosa, será fundamental.

A recomendação de mesa separada de Tom H também é uma boa ideia.

BrianV está correto. É difícil dar uma regra porque varia drasticamente com base em como você usará a tabela, como ela é indexada, as colunas reais na tabela etc.

Quanto às práticas comuns ... para tabelas muito grandes, você pode considerar o particionamento. Isso pode ser especialmente útil se você achar que, para o seu log, você normalmente se importa apenas com alterações no último mês (ou 1 dia, 1 semana, 1 ano, o que quer que seja). Você pode então arquivar as partes mais antigas dos dados para que fiquem disponíveis se for absolutamente necessário, mas não estarão no caminho, já que você quase nunca precisará delas.

Outra coisa a considerar é ter uma tabela de log de alterações separada para cada uma das suas tabelas reais se você ainda não estiver planejando fazer isso. Usar uma única tabela de log torna muito difícil trabalhar com ela. Você geralmente precisa registrar as informações em um campo de texto de formato livre que é difícil de consultar e processar. Além disso, é difícil examinar os dados se você tiver uma linha para cada coluna que foi alterada, pois é necessário fazer muitas junções para examinar as alterações que ocorrem ao mesmo tempo lado a lado.

Você está certo de que o número de linhas é limitado pelo seu armazenamento disponível.

É difícil fornecer números, pois depende muito do hardware do servidor, da configuração e da eficiência das suas consultas.

Por exemplo, uma instrução select simples será executada mais rapidamente e mostrará menos degradação do que uma pesquisa em texto completo ou proximidade, à medida que o número de linhas aumentar.

Com as tabelas de auditoria, outra abordagem é arquivar os dados uma vez por mês (ou semana, dependendo da quantidade de dados que você coloca nele) ou mais. Dessa forma, se você precisar recriar algumas mudanças recentes com os novos dados, isso pode ser feito em tabelas menores e, portanto, mais rapidamente (recuperar de tabelas de auditoria é quase sempre uma tarefa urgente que eu encontrei!). Mas você ainda tem os dados disponíveis para o caso de precisar voltar mais no tempo.