Czy sys.stats_columns jest niepoprawny?

28

Powiedzmy, że mam zdefiniowaną tabelę Fooz kolumnami ID1, ID2i złożonym kluczem podstawowym ID2, ID1. (Obecnie pracuję z produktem System Center, który ma kilka tabel zdefiniowanych w ten sposób, a kolumny klucza podstawowego są wymienione w odwrotnej kolejności niż w definicji tabeli).

CREATE TABLE dbo.Foo(
  ID1 int NOT NULL,
  ID2 int NOT NULL,
CONSTRAINT [PK_Foo] PRIMARY KEY CLUSTERED (ID2, ID1)
);
GO

-- Add a row and update stats so that histogram isn't empty
INSERT INTO Foo (ID1, ID2) VALUES (1,2);
UPDATE STATISTICS dbo.Foo;

key_ordinalKolumna sys.index_columnspokazuje kolumn indeksu w tej samej kolejności, w jakiej zostały zgłoszone w kompozytowej klucz podstawowy:

SELECT t.name, i.name, c.column_id, c.name, ic.index_column_id, ic.key_ordinal
FROM sys.tables AS t
JOIN sys.indexes AS i
ON t.[object_id] = i.[object_id]
JOIN sys.index_columns AS ic
ON ic.[object_id] = i.[object_id]
AND ic.index_id = i.index_id
JOIN sys.columns AS c
ON ic.column_id = c.column_id
AND ic.[object_id] = c.[object_id]
WHERE t.name = 'Foo';

indeks

Histogram pokazuje również statystyki w tej samej kolejności:

DBCC SHOW_STATISTICS ('Foo',PK_Foo);

statystyki

Jednakże sys.stats_columnswskazuje kolumny wymienione w kolejności odwrotnej ( ID1, ID2).

SELECT s.name, sc.stats_column_id, c.name
FROM sys.stats AS s
JOIN sys.stats_columns AS sc 
ON s.stats_id = sc.stats_id 
AND s.[object_id] = sc.[object_id] 
JOIN sys.columns AS c 
ON c.[object_id] = s.[object_id]
AND c.column_id = sc.column_id
JOIN sys.objects AS o 
ON o.[object_id] = c.[object_id] 
WHERE o.name = 'Foo'
AND s.name = 'PK_Foo';

stats_columns

Books Online mówi, że stats_column_idjest „porządkiem opartym na 1 w zestawie kolumn statystyk”, więc spodziewałem się, że wartość 1 będzie wskazywała na pierwszą kolumnę w obiekcie statystyki.

Czy to błąd, sys.stats_columnsczy nieporozumienie z mojej strony?

Zweryfikowałem, że takie zachowanie występuje w bieżących wersjach SQL Server 2005, 2008, 2008 R2, 2012 i 2014.

sys.stats_columns wydaje się odzwierciedlać kolejność w obiekcie statystyki w innych sytuacjach, na przykład:

CREATE TABLE dbo.Foo2(
  ID1 int NOT NULL,
  ID2 int NOT NULL,
  ID3 int NULL,
  String VARCHAR(10) NULL,
CONSTRAINT [PK_Foo2] PRIMARY KEY CLUSTERED (ID2, ID1)
);

GO

INSERT INTO Foo2 (ID1, ID2, ID3, String) VALUES (1,2,3,'String');

CREATE STATISTICS ST_Test ON Foo2 (ID3, String);
CREATE STATISTICS ST_Test2 ON Foo2 (String, ID3);

DBCC SHOW_STATISTICS ('Foo2',ST_Test);
DBCC SHOW_STATISTICS ('Foo2',ST_Test2);


SELECT s.name, sc.stats_column_id, c.name
FROM sys.stats AS s
JOIN sys.stats_columns AS sc 
ON s.stats_id = sc.stats_id 
AND s.[object_id] = sc.[object_id] 
JOIN sys.columns AS c 
ON c.[object_id] = s.[object_id]
AND c.column_id = sc.column_id
JOIN sys.objects AS o 
ON o.[object_id] = c.[object_id] 
WHERE o.name = 'Foo2'
AND s.name LIKE 'ST_Test%';

morestats

Oto kolejny przykład, w którym sys.stats_columnswydaje się zwracać poprawne dane, tym razem dla statystyk dotyczących indeksu:

--drop table dbo.Foo3
CREATE TABLE dbo.Foo3(
  ID1 int NOT NULL,
  ID2 int NOT NULL,
  ID3 int NULL,
  String VARCHAR(10) NULL,
CONSTRAINT [PK_Foo3] PRIMARY KEY CLUSTERED (ID2, ID1)
);

GO

INSERT INTO Foo3 (ID1, ID2, ID3, String) VALUES (1,2,3,'String');
UPDATE STATISTICS Foo3;

CREATE INDEX IX_Test ON Foo3 (ID3, String);
CREATE INDEX IX_Test2 ON Foo3 (String, ID3);

DBCC SHOW_STATISTICS ('Foo3',IX_Test);
DBCC SHOW_STATISTICS ('Foo3',IX_Test2);

SELECT s.name, sc.stats_column_id, c.name
FROM sys.stats AS s
JOIN sys.stats_columns AS sc 
ON s.stats_id = sc.stats_id 
AND s.[object_id] = sc.[object_id] 
JOIN sys.columns AS c 
ON c.[object_id] = s.[object_id]
AND c.column_id = sc.column_id
JOIN sys.objects AS o 
ON o.[object_id] = c.[object_id] 
WHERE o.name = 'Foo3'
AND s.name LIKE 'IX_Test%';

więcej morestats

James L.
źródło
3
Kilka miesięcy temu miałem to samo pytanie, ale je usunąłem. Przepraszam za to. Niemniej jednak, stats_column_idw sys.stats_columnsnie wydaje się robić to co mówi to robi. Ponieważ tworzysz kopię indeksu, trzymałbym się kolejności kolumn indeksu. Jeśli patrzysz tylko na obiekty statystyk, wygląda index_col()to na najlepszą obecnie opcję
swasheck
5
Być może powinieneś / powinnaś zgłosić w tym celu element Microsoft Connect? Wydaje mi się, że jest zepsuty.
Max Vernon
6
@MaxVernon, Swashesk złożył tutaj
James L

Odpowiedzi:

5

To wydaje się być długotrwałym błędem:

swasheck - 5 marca 2015 opublikowano:

https://connect.microsoft.com/SQLServer/feedback/details/1163126

MSDN zauważa, że ​​sys.stats_columns.stats_column_id to „liczba porządkowa oparta na 1 w zestawie kolumn statystyk”. Wydaje się jednak, że faktycznie odzwierciedla kolejność definicji tabeli. Zmiana kolejności indeksów nie jest odzwierciedlana w sys.stats_columns.

Max Vernon i James Lupolt wydają się zgadzać na podstawie ich komentarzy / zachęty.

RLF
źródło