För länge sedan brukade jag publicera Connect-sammandrag – små inlägg som lyfte fram några buggrapporter eller förslag på Connect som jag tyckte förtjänade mer uppmärksamhet. Nu ska jag säga så här:Jag är egentligen inte ett stort fan av ett system där personen med flest vänner som är villiga att rösta får sin vilja igenom, eftersom SQL Server-teamet borde kunna ignorera eller skjuta upp brus och fokusera på de viktigaste och mest effektfulla buggarna eller förslagen. Men det är inte så de gör i Redmond . Så idag har jag en begäran:hjälp mig genom att rösta och kommentera dessa tre Connect-objekt, som alla syftar till att förbättra hur SQL Server-statistik fungerar.
(Observera att kommentarer har mycket större vikt än bara rösträkningar, så vänligen ange ditt affärscase, om du har ett som kan delas.)
MAXDOP-tips för UPPDATERA STATISTIK
SQL Server 2016 har lagt till en MAXDOP-tips för DBCC CHECK-kommandon, så varför inte för statistikuppdateringar? På partitionerade tabeller kan detta ha stor inverkan på resten av arbetsbelastningen. Vi borde också kunna åsidosätta den systemdefinierade MAXDOP för automatiska statistikuppdateringar, men för tillfället skulle jag vara nöjd med mer kontroll över manuell statistikhantering. Begäran fångas i följande Connect-objekt:
- Anslut #628971:Lägg till MAXDOP-parameter för att uppdatera statistik
Låt frågeoptimeraren se statistik på partitionsnivå
Erin Stellato har bloggat om fördelarna med inkrementell statistik här, men slog verkligen huvudet på spiken om dess problem i det här inlägget:Inkrementell statistik används INTE av Query Optimizer. Vänligen läs igenom det och rösta sedan och kommentera objektet jag just skapade (jag kan inte fatta att jag aldrig märkt att det inte redan fanns en DCR för detta):
- Anslut #2010834:Optimizer bör faktiskt *använda* statistik per partition
Autostatistik bör ta hänsyn till antalet rader i ett filtrerat index/stat
För närvarande är att förlita sig på automatiska uppdateringar av filtrerade index och statistik som att vänta på Godot – algoritmen använder antalet rader i tabellen när man bestämmer churn-tröskeln, inte antalet rader i indexet. Detta betyder att de flesta filtrerade indexen – och faktiskt de mest användbara filtrerade index – kommer aldrig att uppdateras automatiskt. (Jag pratar om det här, och Kimberly Tripp pratar om det här och här. Jag är säker på att andra har bloggat om det också.) Jag tycker att det är dags att detta ändras – om du håller med, vänligen rösta och kommentera Joe Sacks artikel (titeln indikerar filtrerad statistik, men den hänför sig egentligen till båda):
- Connect #509638 :Föreslå ändring av filtrerade statistikuppdateringar