Encontrei um índice provavelmente abandonado no banco de dados de produção. Ele não está incluído no .sqlproj do qual esse banco de dados geralmente é implantado. Provavelmente foi criado para alguns experimentos e depois deixado lá, mas não tenho certeza. Não é mencionado em nenhuma WITH INDEXdica. Não é usado para um PK ou restrição exclusiva.
Quero ter certeza de que a exclusão desse índice não causará degradação do desempenho. Como eu posso fazer isso?
Eu tenho esta tabela:
CREATE TABLE [dbo].[Accounts] (
[AccountId] UNIQUEIDENTIFIER UNIQUE NOT NULL DEFAULT NEWID(),
-- WHATEVER other columns
);
GO
CREATE UNIQUE CLUSTERED INDEX [AccountsIndex]
ON [dbo].[Accounts]([AccountId] ASC);
GO
Esta consulta:
DECLARE @result UNIQUEIDENTIFIER
SELECT @result = AccountId FROM Accounts WHERE AccountId='guid-here'
executa com um plano de consulta que consiste em uma única busca de índice - como esperado:
SELECT <---- Clustered Index Seek
Esta consulta faz o mesmo:
DECLARE @result UNIQUEIDENTIFIER
SET @result = (SELECT AccountId FROM Accounts WHERE AccountId='guid-here')
mas é executado com um plano em que o resultado do Index Seek é Left Outer Joined com o resultado de alguma Constant Scan e, em seguida, alimentado no Compute Scalar:
SELECT <--- Compute Scalar <--- Left Outer Join <--- Constant Scan
^
|------Clustered Index Seek
O que é essa magia extra? O que faz a Varredura Constante seguida pela Junção Externa Esquerda?
Observamos recentemente uma grave degradação de desempenho em um banco de dados SQL Azure em execução no nível de desempenho Standard3 - a utilização da CPU passou de dez por cento para cinquenta por cento para quase cem por cento em apenas uma hora. Portanto, alteramos o nível de desempenho para Premium2 e a utilização da CPU caiu imediatamente para cerca de oito por cento.
O Standard3 oferece 100 DTUs e o Premium2 oferece 250 DTUs. O que significa que oito por cento de P2 são apenas vinte DTUs, o que está muito longe de usar todas as 100 DTUs no Standard3.
Essas DTUs são diferentes? Caso contrário, como é possível essa queda repentina de utilização ao mudar de um nível de desempenho de 100 DTUs para um nível de desempenho de 250 DTUs?
Eu tenho essas definições de tabela herdadas ( a partir daqui ):
CREATE TABLE [dbo].[JobItems] (
[ItemId] UNIQUEIDENTIFIER NOT NULL,
-- lots of other columns
CONSTRAINT [PrimaryKey_GUID_HERE] PRIMARY KEY NONCLUSTERED ([ItemId] ASC)
);
CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
ON [dbo].[JobItems]([ItemId] ASC);
que efetivamente produz dois índices idênticos. Quero me livrar de um deles para reduzir o tempo de inserção e liberar espaço em disco.
A tabela é armazenada em um banco de dados SQL Azure de produção, portanto, não posso reconstruir a tabela e não posso descartar o índice clusterizado (o SQL Azure requer um índice clusterizado para cada tabela).
Meu requisito é manter todas as garantias de integridade de dados fornecidas pela definição original e me livrar do índice não clusterizado. Parece que ter uma NOT NULLrestrição e um índice exclusivo me dá as mesmas garantias que uma restrição PK. Portanto, a restrição PK é redundante e posso eliminá-la e ao índice subjacente.
Posso simplesmente descartar a restrição PK aqui sem esperar que algo seja interrompido?
Isso faz parte da definição da tabela daqui :
CREATE TABLE [dbo].[JobItems] (
[ItemId] UNIQUEIDENTIFIER NOT NULL,
-- lots of other columns
CONSTRAINT [PrimaryKey_GUID_HERE] PRIMARY KEY NONCLUSTERED ([ItemId] ASC)
);
CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
ON [dbo].[JobItems]([ItemId] ASC);
Este é um design herdado, então, por favor, não pergunte "por quê". De qualquer forma, quando procuro a lista de índices, vejo que há dois índices - um deles é JobItemsIndexe o outro é PK-GUID-HEREe ambos são para JobItemstabela.
Minha pergunta é...
Por que há necessidade de um índice separado para manter o PK quando eu já tenho JobItemsIndexum único e inclui a mesma coluna e, portanto, adequado para manter a restrição PK?
Eu tenho a seguinte definição:
CREATE TABLE [dbo].[JobItems] (
[ItemId] UNIQUEIDENTIFIER NOT NULL,
[ItemState] INT NOT NULL,
[ItemCreationTime] DATETIME NULL DEFAULT GETUTCDATE(),
[ItemPriority] TINYINT NOT NULL DEFAULT(0),
[ItemRefreshTime] DATETIME NULL,
-- lots of other columns
CONSTRAINT [PrimaryKey_GUID_HERE] PRIMARY KEY NONCLUSTERED ([ItemId] ASC)
);
CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
ON [dbo].[JobItems]([ItemId] ASC);
CREATE INDEX [GetTaskToProcessIndex]
ON [dbo].[JobItems]([ItemState], [ItemPriority], [ItemCreationTime])
e a seguinte consulta:
SELECT TOP(1) ItemId FROM JobItems
WHERE ItemState = 5 OR
( ( ItemState = 11 ) AND ( DATEDIFF( SECOND, ItemRefreshTime, GETUTCDATE() ) > 14 ) )
ORDER BY ItemPriority ASC, ItemCreationTime ASC
Eu executo esta consulta e inspeciono o plano de execução real e aqui está o que está acontecendo:
ItemState=5.ItemState=11e, em seguida, para cada linha, uma busca separada é feita para recuperar ItemRefreshTimee os resultados de duas buscas são filtrados usando loops aninhados.ItemId, ItemCreationTimee ItemPrioritysão concatenados e então...DistinctSortacontece com ORDER BY ItemId ASCe finalmenteTopNSortacontece comORDER BY ItemPriority ASC, ItemCreationTime ASCTopNSorte DistinctSortpegar algo como 32 por cento cada, então ficaria feliz em me livrar DistinctSort- nem mesmo entendo seu propósito.
O que é este mágico TopNSortque é útil DistinctSorte por que ele está lá?
Tenho um banco de dados SQL Azure com as seguintes tabelas:
CREATE TABLE [dbo].[UserBalances]
(
[UserId] UNIQUEIDENTIFIER UNIQUE NOT NULL DEFAULT NEWID(),
[AvailableMoney] INT NOT NULL DEFAULT(0)
);
GO
CREATE UNIQUE CLUSTERED INDEX [UserBalancesIndex]
ON [dbo].[UserBalances]([UserId] ASC);
GO
CREATE TABLE [dbo].[UserBalanceChanges]
(
[EntryId] UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID(),
[UserId] UNIQUEIDENTIFIER NOT NULL,
[PriorBalance] INT NOT NULL,
[NewBalance] INT NOT NULL,
[Time] DATETIME DEFAULT(GETUTCDATE())
)
GO
CREATE CLUSTERED INDEX UserBalanceChangesIndex
ON [UserBalanceChanges]( EntryId )
GO
e o seguinte código sendo executado simultaneamente por meio de várias conexões com o banco de dados:
CREATE PROCEDURE [dbo].[usp_ChangeUserBalance] @userId UNIQUEIDENTIFIER,
@change INT
AS
BEGIN TRANSACTION
DECLARE @priorBalance INT;
DECLARE @newBalance INT;
DECLARE @updateTime DATETIME;
UPDATE dbo.UserBalances
SET @updateTime = GETUTCDATE(),
@priorBalance = AvailableMoney,
@newBalance = AvailableMoney = AvailableMoney + @change
WHERE UserId = @userId;
INSERT INTO UserBalanceChanges
(UserId,
PriorBalance,
NewBalance,
Time)
VALUES ( @userId,
@priorBalance,
@newBalance,
@updateTime );
COMMIT TRANSACTION
RETURN 0
e então eu executo a seguinte consulta:
SELECT TOP(1000) PriorBalance,
NewBalance
FROM UserBalanceChanges
WHERE UserId = SomeSpecificId
ORDER BY Time DESC
e muitas vezes vejo algo assim:
1000 995
1005 1000 <<identical
1005 1000 <<changes
1010 1005
1015 1010
que parece que as duas atualizações em execução simultânea leem o mesmo valor inicial e, em seguida, uma atualização é efetivamente perdida.
Atualizações perdidas são uma anomalia conhecida, mas atualizações perdidas são impossíveis no SQL Server e presumivelmente no SQL Azure também (pelo menos com uma única instrução "SELECT from UPDATE" que eu tenho.
No entanto, parece que realmente vejo atualizações perdidas.
Por que observo atualizações perdidas "impossíveis"?
Quando me conecto a algum site de e-commerce com meu navegador eu uso HTTPS que usa um certificado que (mais ou menos) garante que example.comé de fato example.com.
Agora eu me conecto a um SQL Server em algum lugar na Internet - pode ser o SQL Azure, por exemplo, e então apenas me conecto a uma URL como abcdef.database.windows.net. Há uma chance de haver um servidor falso lá e eu expor meus dados confidenciais. Não encontrei nenhuma evidência de que certificados ou qualquer coisa equivalente sejam usados ao conectar-se ao SQL Server.
Como a identidade do host do SQL Server é garantida?
Eu tenho uma tabela Unitsonde tenho linhas ItemId, ItemCreationDate, ItemUnitsCount. ItemIdé uma chave primária e eu tenho um índice clusterizado sobre ela.
Preciso produzir o seguinte: para cada dia preciso contar separadamente
ItemUnitsCountItemUnitsCounte imprima a contagem e a data e em qualquer dia pode haver qualquer número de itens de ambos os tipos, talvez nenhum. Cada tipo de item deve ser relatado separadamente , então para qualquer dia eu não posso ter linhas, uma linha ou duas linhas.
Então criei a seguinte consulta:
(SELECT ItemCreationDate, COUNT(ItemId) AS ComputedCount, 1 AS CountType
FROM Items WHERE ItemUnitsCount<>0 GROUP BY ItemCreationDate )
UNION ALL
(SELECT ItemCreationDate, COUNT(ItemId) AS ComputedCount, 2 AS CountType
FROM Items WHERE ItemUnitsCount=0 GROUP BY ItemCreationDate )
e isso funciona bem, mas quando olho para o plano de execução real, vejo duas varreduras de índice clusterizado, uma das quais tem predicate ItemUnitsCount=0e outra tem predicate ItemUnitsCount<>0.
ItemUnitsCountpode ser alterado várias vezes durante o tempo de vida da linha da tabela, portanto, prefiro não criar um índice para ele.
Existe uma maneira de criar uma consulta com o mesmo efeito que resulta em uma varredura de índice em vez de duas?
Suponha que eu tenha uma tabela Stuffcom uma coluna Citye nenhum índice incluindo essa coluna. Eu preencho a tabela. Então eu decido criar um índice:
CREATE INDEX [StuffOnCityIndex] ON [dbo].[Stuff](City ASC);
e o banco de dados confirma que foi bem- CREATE INDEXsucedido.
O índice recém-criado incluirá imediatamente todas as entradas existentes da tabela ou será construído lentamente "em segundo plano"? Em outras palavras, se eu achar que a criação de um índice melhorará o desempenho, verei essa melhoria imediatamente após a CREATE INDEXconclusão?