Temos duas tabelas com colunas e índices idênticos (sem indexação, basicamente). Executamos a mesma consulta, que no caso da tabela original leva 5 segundos para ser executada; no caso da nova tabela, deixamos rodar por 30 minutos e depois matamos a consulta.
Atualizamos as estatísticas, mas isso não teve resultado. Tentamos reconstruir a nova tabela para ver se a desfragmentação ajudaria, mas também não surtiu efeito.
Em um palpite, exportamos as duas tabelas para o mesmo banco de dados, a fim de ver se algo mudaria ou não, mas temos exatamente os mesmos resultados.
Estou meio perplexo como isso pode ser. Para tornar as coisas ainda mais interessantes, a tabela original contém mais dados do que a nova tabela, o que teoricamente significa que a nova tabela deve concluir a consulta mais rapidamente.
Alguém tem uma possível explicação? Eu trabalhei por anos como DBA (embora não por alguns anos agora) e, francamente, estou perplexo sobre o motivo pelo qual isso poderia acontecer.
Em resposta a alguns dos comentários, aqui está a definição da tabela em questão:
CREATE TABLE [dbo].[Fact_SubscriptionDetail_Test](
[CustomerSellTo_Key] [int] NULL,
[CustomerContactSellTo_Key] [int] NULL,
[CustomerRefTo_Key] [int] NULL,
[WebAuthUser_Key] [int] NULL,
[Country_Key] [int] NULL,
[Date_Key] [int] NULL,
[SnapshotDate_Key] [int] NULL,
[Product_Key] [int] NULL,
[License_Key] [int] NULL,
[Subscription_Key] [int] NULL,
[SubscriptionTypeLostSeatsType_Key] [int] NULL,
[M_SubscriptionDetail_NewSeats] [int] NULL,
[M_SubscriptionDetail_WinbackSeats] [int] NULL,
[M_SubscriptionDetail_RenewedFlexSeats] [int] NULL,
[M_SubscriptionDetail_RenewedCommitSeats] [int] NULL,
[M_SubscriptionDetail_RenewedSeats] [int] NULL,
[M_SubscriptionDetail_ActiveSeatsEndMonth] [int] NULL,
[M_SubscriptionDetail_LostNonPaymentSeats] [int] NULL,
[M_SubscriptionDetail_LostGraceInactiveSeats] [int] NULL,
[M_SubscriptionDetail_LostOtherSeats] [int] NULL,
[M_SubscriptionDetail_LostSeats] [int] NULL,
[M_SubscriptionDetail_GrossBookings] [numeric](38, 20) NULL,
[M_SubscriptionDetail_ActiveFlexSeats] [int] NULL,
[M_SubscriptionDetail_ActiveCommitSeats] [int] NULL,
[M_SubscriptionDetail_ActiveSeats] [int] NULL,
[DateCreated] [datetime] NULL
CONSTRAINT [DF__Fact_Subs__DateC__gtfhjCC] DEFAULT (getdate())
) ON [DATA]
Os dados nas duas tabelas não são totalmente idênticos, mas de natureza muito semelhante. A consulta que executamos está vinculada a algumas outras tabelas (principalmente dimensões do data warehouse).
Eu desfragmentei (o que eu concordo, não faz muito sentido para um heap, mas achei que não faria e não faria mal) simplesmente executando
ALTER TABLE Fact_SubscriptionDetail_Test REBUILD.
Quando verificamos inicialmente o plano de consulta, ele sugeriu adicionar alguns índices na tabela Teste (mas não na tabela rápida original). Também tentamos adicionar um índice clusterizado (PK) na tabela Teste, mas nem isso, nem o índice sugerido pelo Plano de Execução teve qualquer efeito.
Seguem os planos de execução:
http://pastebin.com/XagvSxjj (Tabela original; rápido)
http://pastebin.com/LSgCsvUe (Nova tabela; lento)
Há uma diferença nos caminhos de execução, o que me faz pensar que a cardinalidade dos dados na tabela original é um pouco melhor. A tabela original contém cerca de 1,4 milhão de linhas (230 MB), das quais 400 mil são processadas pela consulta. A nova tabela contém 400 mil linhas (52 MB).
Esta é a consulta completa: http://pastebin.com/bYiaGW1d (ligeiramente editada para remover algumas informações confidenciais).
O valor para "limite de custo para paralelismo" no servidor é 5.