Powiedzmy, że mam zdefiniowaną tabelę Foo
z kolumnami ID1, ID2
i 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_ordinal
Kolumna sys.index_columns
pokazuje 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';
Histogram pokazuje również statystyki w tej samej kolejności:
DBCC SHOW_STATISTICS ('Foo',PK_Foo);
Jednakże sys.stats_columns
wskazuje 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';
Books Online mówi, że stats_column_id
jest „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_columns
czy 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%';
Oto kolejny przykład, w którym sys.stats_columns
wydaje 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%';
źródło
stats_column_id
wsys.stats_columns
nie 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ądaindex_col()
to na najlepszą obecnie opcjęOdpowiedzi:
To wydaje się być długotrwałym błędem:
swasheck - 5 marca 2015 opublikowano:
https://connect.microsoft.com/SQLServer/feedback/details/1163126
Max Vernon i James Lupolt wydają się zgadzać na podstawie ich komentarzy / zachęty.
źródło