bigchief's questions

Eu herdei um aplicativo (e banco de dados MS SQL associado) que foi instalado por um fornecedor de software há muitos anos. Não temos nenhum tipo de suporte de fornecedor neste momento. Além de usar o aplicativo, também acessamos o banco de dados independentemente do aplicativo, muitas vezes fazendo atualizações no banco de dados diretamente e consultando dados para geração de relatórios.

Em um esforço para melhorar o desempenho, excluí alguns índices desnecessários e criei outros. Isso causava bugs no aplicativo ao executar determinadas tarefas. O aplicativo não exibe nenhuma mensagem de erro de qualquer tipo e parece funcionar normalmente, mas o banco de dados não é atualizado pelo aplicativo conforme o esperado. Não tenho acesso ao código fonte.

Minha teoria é que o aplicativo especifica explicitamente um índice excluído em uma instrução with(index) em uma de suas consultas. Isso faria com que o servidor retornasse um erro em vez de concluir a consulta e, se o aplicativo suprimisse o erro, o usuário não saberia que algumas tabelas foram atualizadas e outras não. Que outras ideias poderiam causar esse comportamento?

Supondo que minha teoria esteja correta, ainda acredito que o índice seja realmente desnecessário e o aplicativo nunca deveria ter especificado o índice. Talvez uma solução seja criar um novo índice com o mesmo nome, mas com a menor quantidade de colunas possível. Existe alguma maneira de criar um índice sem colunas? Criar um índice não clusterizado com as mesmas colunas do índice clusterizado seria o mais eficiente? O que o otimizador faz neste caso - ele ainda planeja incluir esses índices "ruins" que apenas fazem referência ao índice clusterizado ou saberá ignorar a solicitação with(index)?

Eu executei um rastreamento para ver quais consultas o aplicativo estava executando. Recebi várias chamadas RPC como "exec sp_cursorfetch" e "exec sp_cursorexecute" (que não entendo) em vez do SQL real. Talvez eu pergunte sobre isso em uma pergunta separada, mas se você souber como posso interpretar ou decodificar essas instruções em SQL regular, isso me permitiria pelo menos confirmar minha teoria.

No meu banco de dados tenho uma tabela com dois índices. Há um índice exclusivo nº 1 nas colunas a,b que preciso por motivos de integridade de dados. Eu tenho outro índice #2 com colunas c,a,b que é usado por motivos de desempenho. Percebi que este índice #2 também é único.

A singularidade do índice #2 me parece redundante, pois você não pode ter valores duplicados no índice #2 sem também ter valores duplicados no índice #1. Estou tentado a alterar o índice #2 para que ele não seja mais exclusivo, porque imagino que o mecanismo de banco de dados possa executar uma segunda verificação em c,a,b no índice #2 para garantir a exclusividade dessas colunas toda vez que uma linha for inserida, causando um impacto no desempenho, mesmo que nunca haja valores duplicados. Isso está correto?

Existe alguma maneira de excluir o índice #1 em a,b e manter o índice #2 em c,a,b, mas ainda forçar uma restrição exclusiva apenas nas colunas a,b sem manter dois índices separados? Isso me permitiria ter apenas um índice com todas as três colunas, mas ainda aplicaria minha restrição de integridade de dados em a,b. Não preciso de um índice em a,b para desempenho porque todas as minhas consultas de seleção incluem a coluna c na cláusula where. Este seria um caso de uso para uma restrição exclusiva em vez de um índice? Eu pensei que o mecanismo de banco de dados basicamente trata essas duas construções da mesma forma (veja este post: Quando devo usar uma restrição exclusiva em vez de um índice exclusivo? ).

Tenha em mente que os índices não são redundantes, mas a "singularidade" dos índices é redundante. Parece que é um acéfalo tornar o índice # 2 não exclusivo. Mas isso resulta em algum ganho real de desempenho? O banco de dados verifica a exclusividade de ambos os índices mesmo que as colunas no índice #1 estejam totalmente incluídas no índice #2?

Algumas respostas perguntaram sobre consultas de exemplo usadas para selecionar dados dessa tabela. Aqui estão os mais comuns:

Select [some other columns] from table where c=1 and a=2
Select [some other columns] from table where c=1
Select [some other columns] from table where c=1 and a=2 and b=3

Essas consultas geralmente incluem a seleção de muitas outras colunas que não estão em nenhum índice.

O que normalmente nunca executamos é uma consulta como esta:

Select [stuff] from table where a=2 and b=3