Triynko's questions

Alguém disse que é preferível criar suas consultas para evitar exceções de chave duplicadas, mas não estou convencido de que seja mais eficiente do que apenas definir IGNORE_DUP_KEY = ONo índice.

Meu objetivo é garantir que uma linha ou conjunto de linhas exista para um ou mais usuários antes de tentar atualizar essas linhas. Eu faço isso para que, quando tento atualizar a linha com uma instrução de atualização como a abaixo, e nenhuma linha seja afetada, é porque a [Count]parte do predicado não foi satisfeita, ao contrário da linha que não existe (ou seja, a [ID]parte do predicado não sendo satisfeita):

UPDATE [Inventory]
SET [Count] = [Count] + 1
WHERE [ID] = 3 
AND ([Count] + 1) <= @MaxInventory

Eu poderia executar EXISTS(SELECT 1 From [Inventory] WHERE [ID] = 3para verificar essa única linha e inserir a linha apenas se ela não existir. Isso simplesmente evita inserções desnecessárias. A inserção, se necessário, ainda teria que lidar com transações simultâneas, portanto, exceções de chave duplicada ainda podem ocorrer.

Estou curioso para saber se é mais eficiente apenas ativar IGNORE_DUP_KEYneste cenário, em vez de permitir que o erro seja lançado e capturado. Especificamente, estou curioso para saber se é tão rápido ou possivelmente ainda mais rápido do que executar uma verificação existente, apenas para tentar inserir o registro e deixá-lo ignorar chaves duplicadas.

Isso se torna ainda mais importante quando estou verificando e inicializando vários registros ao mesmo tempo. Por exemplo, se eu precisar garantir que os registros de milhares de usuários existam em uma única instrução de atualização, a lógica seria muito mais simples se eu apenas executasse essa instrução de inserção antecipadamente, permitindo que ela ignorasse chaves duplicadas. Evitar duplicatas seria mais complexo, porque eu teria que primeiro consultar a tabela para a qual os registros não existem e, em seguida, tentar adicionar apenas esses registros (novamente, ignorando as chaves duplicadas). Apenas inserir pode ser mais rápido, mesmo que todos os registros existam.

Eu poderia encontrá-lo no meio do caminho e verificar se algum dos registros está faltando, como com uma junção à esquerda ou uma COUNTcomparação, mas por que se preocupar se a inserção ignorando chaves duplicadas é apenas mais rápida?

É uma boa ideia usar IGNORE_DUP_KEYe apenas tentar inserções em vez de se preocupar em verificar a existência de linhas antes do tempo? Se não, por quê?

Existe uma tabela de "consulta em lote" que possui duas colunas (BatchID, RecordID) que são ambas do tipo TSQL 'uniqueidentifier'. A chave de cluster exclusiva está ativada (BatchID, RecordID) e não há índices secundários.

Usamos SqlBulkCopy para inserir rapidamente milhares ou milhões de IDs na tabela em um único ID de lote, para que várias consultas possam se unir a ele para realizar a filtragem usando esse conjunto de IDs de registro associados a esse lote. Essa abordagem é muito mais rápida do que tentar várias consultas que enviam listas de IDs na string de consulta. Assim que as consultas forem concluídas, o lote de IDs de registro será excluído. A tabela fica vazia em média quando nenhuma consulta está em execução, mas pode ter centenas de lotes ativos, pois processamos milhares de solicitações de API por segundo que podem usar a tabela.

Minha pergunta é, que tipo de etapas de manutenção, se houver, são exigidas de um DBA para manter essas tabelas. Por exemplo, ele se beneficiaria da reconstrução periódica do índice ou o SQL Server lidaria com a limpeza das linhas excluídas (liberando blocos de página etc.) sozinho. Além disso, existe alguma configuração especial da tabela ou índice clusterizado que ajudaria, especialmente considerando que os identificadores são Guids aleatórios (identificadores exclusivos).

Geralmente usamos a versão mais recente do SQL Server, Enterprise Edition. Alguns servidores estão no Azure, alguns na AWS.

Também estou interessado em ouvir alternativas. Por exemplo, suponho que essa abordagem seja melhor com uma tabela permanente, mas também posso criar uma tabela temporária local de sessão como parte de uma transação que é excluída quando concluída, em vez de inserir e excluir linhas de uma tabela permanente. Só não sei como isso funcionaria em comparação.

select POWER(2.,64.)retorna 18446744073709552000em vez de 18446744073709551616. Parece ter apenas 16 dígitos de precisão (arredondando o 17º).

Mesmo tornando a precisão explícita select power(cast(2 as numeric(38,0)),cast(64 as numeric(38,0))), ela ainda retorna o resultado arredondado.

Esta parece ser uma operação bastante básica para que ela esteja lascando arbitrariamente em 16 dígitos de precisão como esta. O máximo que ele pode calcular corretamente é apenas POWER(2.,56.), falhando por POWER(2.,57.). O que está acontecendo aqui?

O que é realmente terrível é que select 2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.;realmente retorna o valor correto. Tanto para concisão.