O ile nie rozumiem celu kolumny, poniższy kod wskazuje, że zmiana struktury indeksu klastrowego nie zmienia pozycji porządkowej ( stats_column_id
) kolumny w sys.stats_columns DMV. (Testowane w AdventureWorks2014, AdventureWorks2008R2)
select i.name, c.name, ic.column_id, ic.index_column_id
from sys.indexes i
join sys.index_columns ic
on i.object_id = ic.object_id
and i.index_id = ic.index_id
join sys.columns c
on i.object_id = c.object_id
and ic.column_id = c.column_id
where i.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID'
order by ic.key_ordinal;
select sh.name,s.name, c.name, c.column_id, sc.column_id, sc.stats_column_id
from sys.stats s
join sys.stats_columns sc
on s.object_id = sc.object_id
and s.stats_id = sc.stats_id
join sys.columns c
on s.object_id = c.object_id
and sc.column_id = c.column_id
join sys.tables t
on s.object_id = t.object_id
join sys.schemas sh
on t.schema_id = sh.schema_id
where s.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID'
order by sc.stats_column_id;
dbcc show_statistics('[Person].[BusinessEntityAddress]','PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID') with density_vector;
ALTER TABLE [Person].[BusinessEntityAddress] DROP CONSTRAINT [PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID]
GO
ALTER TABLE [Person].[BusinessEntityAddress] ADD CONSTRAINT [PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID] PRIMARY KEY CLUSTERED
(
AddressID ASC,
[BusinessEntityID] ASC,
[AddressTypeID] ASC
)
GO
select i.name, c.name, ic.column_id, ic.index_column_id
from sys.indexes i
join sys.index_columns ic
on i.object_id = ic.object_id
and i.index_id = ic.index_id
join sys.columns c
on i.object_id = c.object_id
and ic.column_id = c.column_id
where i.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID'
order by ic.key_ordinal;
select sh.name,s.name, c.name, c.column_id, sc.column_id, sc.stats_column_id
from sys.stats s
join sys.stats_columns sc
on s.object_id = sc.object_id
and s.stats_id = sc.stats_id
join sys.columns c
on s.object_id = c.object_id
and sc.column_id = c.column_id
join sys.tables t
on s.object_id = t.object_id
join sys.schemas sh
on t.schema_id = sh.schema_id
where s.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID'
order by sc.stats_column_id;
dbcc show_statistics('[Person].[BusinessEntityAddress]','PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID') with density_vector;
Jednak wektory gęstości wskazują zmianę w wiodącej kolumnie obiektu indeksu / statystyki. Czy to fundamentalne nieporozumienie z mojej strony? Jeśli tak, to jak znaleźć wiodącą kolumnę obiektu statystycznego za pomocą DMV?
Testowane wersje SQL Server: 2008R2, 2014
sql-server
statistics
dmv
swasheck
źródło
źródło
key_ordinal
jest kolejnością kolumn indeksu (właśnie to odkryłem). jednak dokumentacja sys.stats_columns wydaje się wskazywać, że stats_column_id jest pozycją porządkową, ale mógłbym odczytać to całkowicie błędnie.INDEX_COL()
choć niejasno przypominam sobie kogoś, kto zauważył, że te funkcje pomocnika mogą nie być najlepszym pomysłemOdpowiedzi:
Według wszystkich kont może to być błędne zachowanie w sys.stats_columns DMV. Wydaje się to powodować problemy, gdy statystyki są aktualizowane za pomocą indeksu nadrzędnego. Uważam, że jest to spowodowane mechanizmem, za pomocą którego statystyki są aktualizowane w ramach zmiany ograniczenia.
Jeśli utworzysz statystykę ręcznie, a następnie zechcesz zmienić kolumny, musisz najpierw usunąć i ponownie utworzyć, co wymusza aktualizację metadanych w danym DMV. W pokazanej operacji wydaje się, że po wprowadzeniu zmiany metadane nie są aktualizowane w żadnych okolicznościach (DBCC *, CHECKPOINT, restart serwera, aktualizacja statystyk poprzez zmianę indeksu nadrzędnego itp.). Z moich początkowych testów mogę znaleźć tylko jeden przypadek, gdy metadane są odpowiednio aktualizowane, czyli scenariusz upuszczenia i odtworzenia.
Możesz rzucić okiem na element Connect w danej sprawie i odpowiednio głosować. Jest tam opublikowane obejście zapytania, ale jego mechanizm polega na dopasowaniu nazwy indeksu do nazwy statystyki i wykorzystaniu metadanych indeksu.
źródło
Miałem ten sam problem podczas próby odtworzenia sposobu, w jaki inni pobierają informacje o indeksie z widoków sys.dm w programie SQL Server. Po prostu nie mogłem ustalić kolejności kolumn w indeksie.
Oto skrypt, który utworzyłem w celu ustalenia kolejności kolumn w danym indeksie dla danej tabeli:
Kolumna
key_ordinal
w tabeli sys.index_columns to kolejność przechowywania kolumn w indeksie.Nie ma
key_ordinal
kolumny dlasys.stats_columns
tabeli. Kolumnastats_column_id
po prostu replikujeindex_column_id
kolumnę obiektu, do którego się odwołuje.Istnieje niewielka różnica w brzmieniu artykułu sys.stats_columns (Transact-SQL) dla kolumny
stats_column_id
:... oraz w artykule sys.index_columns (Transact-SQL) dla
key_ordinal
kolumny:Uważam, że
index_column_id
(sys.index_columns) istats_column_id
(sys.stats_columns) są sobie równoważne i że tylko tabela sys.index_columns ma kolumnę porządkową, mianowiciekey_ordinal
.źródło