Início / dba / Perguntas / 189228
Accepted
Andrew Williamson
Asked: 2017-10-25 11:58:28 +0800 CST

Os números de partição são garantidos em ordem de valor?

  • 772

Digamos que eu tenha uma tabela particionada, configurada assim:

CREATE PARTITION FUNCTION PF_Month (DATE) AS RANGE RIGHT FOR VALUES (
  '2017-01-01',
  '2017-02-01',
  '2017-03-01',
  '2017-04-01',
  '2017-05-01',
  '2017-06-01',
);
GO

CREATE PARTITION SCHEME PS_Month AS PARTITION PF_Month ALL TO ([Primary]);
GO

CREATE TABLE Logs
(
     Id           INT NOT NULL,
     DateRecorded DATE NOT NULL,
     FixStatus    INT NOT NULL
);
GO

ALTER TABLE Logs
    ADD CONSTRAINT PK_Logs PRIMARY KEY (Id, DateRecorded)
    ON PS_Month(DateRecorded);
GO

CREATE NONCLUSTERED INDEX [IX_DateRecorded] ON Logs(DateRecorded)
    INCLUDE(FixStatus)
    ON PS_Month(DateRecorded);
GO

Se eu quiser consultar os logs, em ordem de data, me disseram que posso usar o número da partição para evitar uma classificação quando os resultados de cada partição forem reunidos novamente.

SELECT * FROM Logs WHERE ... ORDER BY $PARTITION.PF_Month(DateRecorded), DateRecorded

Os números das partições estão na ordem de quando cada partição foi criada ou estão na ordem de DateRecorded? Por exemplo, se eu adicionasse outra divisão à função enquanto ela estiver em uso, a ordenação por número de partição ainda funcionaria?

ALTER PARTITION FUNCTION PF_Month() SPLIT RANGE ('2016-12-01')
sql-server partitioning

1 respostas

  1. Best Answer

    Não consegui encontrar uma garantia formal desse comportamento, mas encontrei vários exemplos - incluindo uma versão modificada do seu exemplo original - em que as decisões de otimização de consulta parecem ser feitas com base na garantia de que os números de partição estão em ordem valor. Aqui está o que eu encontrei:

    Seu exemplo

    Seu código de exemplo não é compilado no momento e também usa um índice que não cobre a consulta de exemplo. Aqui está um script atualizado que contém o código de trabalho para seu exemplo original .

    Com essas atualizações, podemos ver que o plano de consulta para sua consulta ORDER BY não inclui um operador de classificação; a otimização de consulta parece depender do fato de que os números de partição são ordenados por valor para omitir a classificação extra.

    -- Create a partition-aligned index that includes all
-- columns in your SELECT statements
CREATE NONCLUSTERED INDEX [IX_DateRecorded] ON Logs(DateRecorded)
     INCLUDE (FixStatus) ON PS_Month(DateRecorded)
GO

-- Now that your index is properly defined, this query produces
-- an ordered index scan without a sort
SELECT * FROM Logs ORDER BY DateRecorded
GO

    Documentação

    Há fortes evidências na documentação de que os números de partição estão em ordem por valor, mas concordo que a documentação em si não é conclusiva. Aqui estão algumas evidências que encontrei:

    A documentação CREATE PARTITION FUNCTION afirma que as partições estarão inicialmente em ordem:

    Se os valores não estiverem em ordem, o Mecanismo de Banco de Dados os classificará, criará a função e retornará um aviso de que os valores não foram fornecidos em ordem.

    A documentação sys.partition_range_values ​​afirma que boundary_id, que parece ser usado para definir o número da partição, é um

    ID (ordinal baseado em 1) da tupla de valor de limite, com o limite mais à esquerda começando em um ID de 1.

    As estatísticas da documentação $PARTITION que

    $PARTITION retorna um valor int entre 1 e o número de partições da função de partição.

    Teste aprofundado

    Com um pouco de teste, podemos ver que há vários casos em que o SQL Server toma decisões de plano de consulta que parecem depender do fato de que os números de partição estão em ordem por valor.

    Aqui está o script de teste completo e algumas das consultas mais relevantes:

    -- The predicate x BETWEEN 4 AND 7 is converted to a range seek
-- on the partition number, strongly indicating that there is a
-- guarantee that partition numbers are in order by value.
-- Seek Keys[1]:
--      Start: PtnId1001 >= Scalar Operator(...[@1]...),
--      End: PtnId1001 <= Scalar Operator(...[@2]...)
SELECT COUNT(*)
FROM dbo.test_partition_ranges
WHERE x BETWEEN 4 AND 7
GO

-- If we change our predicate to use the partition number directly,
-- we see the same seek predicate.
-- Seek Keys[1]:
--      Start: PtnId1001 >= Scalar Operator(...[@1]...),
--      End: PtnId1001 <= Scalar Operator(...[@2]...)
SELECT COUNT(*)
FROM dbo.test_partition_ranges
WHERE $PARTITION.PF_INT_1to10(x) BETWEEN 4 AND 7
GO

-- If we mix conflicting predicates that use values and partition numbers,
-- SQL Server knows that no partitions are eligible.
-- "Actual Partition Count" is 0 and there are 0 logical reads
SELECT COUNT(*)
FROM dbo.test_partition_ranges
WHERE $PARTITION.PF_INT_1to10(x) > 5
    AND x <= 5
GO

-- All 10 partitions are accessed, and ordering by the partition column
-- does not produce a sort! It appears that SQL Server is once again
-- relying on the partition numbers being in order by value.
SELECT x
FROM dbo.test_partition_ranges
ORDER BY x
GO
    • 5

relate perguntas