Yevgeni Grinberg's questions

Ao criar um índice não clusterizado, o nível folha conterá uma referência às linhas da tabela original:

• se a tabela tiver índice clusterizado, o nível folha conterá a chave do índice clusterizado;
• se a tabela não tiver índice clusterizado (um heap), o nível folha conterá um ponteiro para o endereço físico da linha na tabela;

Minha pergunta é por que o índice não clusterizado não foi projetado para conter o endereço físico em ambos os casos (além da chave de índice clusterizado). Ele pode salvar as leituras do B-Tree para pesquisas de chave quando o índice clusterizado é definido.

Eu tenho as duas tabelas a seguir em bancos de dados diferentes:

CREATE TABLE [dbo].[UnitPermission]
(
    [userID] [varchar](10) NOT NULL,
    [unitID] [nvarchar](10) NOT NULL,

    CONSTRAINT [PK_UnitPermission] PRIMARY KEY CLUSTERED 
    (
        [userID] ASC,
        [unitID] ASC
    )
)

e

CREATE TABLE [dbo].[tb_Request]
(
    [ID] [int] NOT NULL,
    [typeID] [int] NOT NULL,
    [statusID] [int] NOT NULL,
    [userUnit] [nvarchar](10) NULL,

    CONSTRAINT [PK_tb_Request] PRIMARY KEY CLUSTERED 
    (
        [ID] ASC
    )
)

com índice não clusterizado

CREATE NONCLUSTERED INDEX [unitIndex] ON [dbo].[tb_Request] 
(
    [userUnit] ASC
)
INCLUDE 
(
    [ID],
    [typeID],
    [statusID]
)

O seguinte procedimento armazenado (não escrito por mim) está causando alguns problemas:

CREATE PROCEDURE [dbo].[sp_GetRequestsByFilter] 
    @userID as varchar(10)

AS
BEGIN

    SELECT 
    dbo.tb_Request.ID,
    dbo.tb_Request.userUnit

    from tb_Request
    inner join otherdb.dbo.UnitPermission on (otherdb.dbo.UnitPermission.unitID = dbo.tb_Request.userUnit or otherdb.dbo.UnitPermission.unitID like '0')
    where otherdb.dbo.UnitPermission.userID = @userID

END

No plano de execução há um Clustered Index Seek em PK_UnitPermission com custo de 94%, Estimated Number of Rows = 1, Actual Number of Rows = 6855.

Seek Predicate:
Prefix: otherdb.dbo.UnitPermission.userID = Scalar Operator (@userID)  
Start: otherdb.dbo.UnitPermission.unitID > Scalar Operator([Expr1016]),
End: otherdb.dbo.UnitPermission.unitID < Scalar Operator([Expr1017])

O que está causando essa falha na estimativa?

Suponho que tenha algo a ver com like '0'on unitID, mas não entendo por que os predicados são criados dessa maneira.

Não posso fornecer o plano de execução. É uma rede local, sem acesso a www.

Tenho a seguinte tabela no meu banco de dados:

create table [dbo].[tb_StatusLog](
[RequestID] [int] not null,
[statusID] [int] not null,
[startTime] [datetime] not null,
[endTime] [datetime] null,
)

com o seguinte índice não agrupado

create nonclusteredindex [index1] on [dbo].[tb_StatusLog]
(
requestID asc, 
statusID asc
)
include ([startTime])

e a seguinte função com valor de tabelafn_getTable

select requestID, max(startTime)
from tb_StatusLog
where statusID=2
group by requestID, statusID

depois de executar o profiler trace e executar os resultados pelo db engine tuning advisor, ele propôs que eu criasse o seguinte índice (que é o mesmo índice que tenho, mas com as colunas de chave invertidas):

create nonclusteredindex [index2] on [dbo].[tb_StatusLog]
(
statusID asc, 
requestID asc
)
include ([startTime])

Agora, ao executar fn_getTable, o plano de execução usa index2em vez de index1e o desempenho é aprimorado.

Por que é que?