sql >> Database teknologi >  >> RDS >> Sqlserver

Hjælp venligst med at forbedre SQL Server-statistikker!

For lang tid siden plejede jeg at udgive Connect-sammendrag – små indlæg, der fremhævede et par fejlrapporter eller forslag om Connect, som jeg syntes fortjente mere opmærksomhed. Nu vil jeg sige dette:Jeg er egentlig ikke en stor fan af et system, hvor den person med flest venner, der er villige til at stemme, får sin vilje, fordi SQL Server-teamet burde være i stand til at ignorere eller udskyde støj og fokusere på de vigtigste og mest virkningsfulde fejl eller forslag. Men det er ikke sådan, de gør i Redmond . Så i dag har jeg en anmodning:hjælp mig ved at stemme og kommentere disse tre Connect-punkter, som alle har til formål at forbedre, hvordan SQL Server-statistikker fungerer.

(Bemærk, at kommentarer har meget større vægt end blot stemmetælling, så angiv venligst din business case, hvis du har en, der kan deles.)

MAXDOP-tip til OPDATERING af STATISTIK

SQL Server 2016 har tilføjet et MAXDOP-tip til DBCC CHECK-kommandoer, så hvorfor ikke til statistikopdateringer? På partitionerede tabeller kan dette have stor indflydelse på resten af ​​arbejdsbyrden. Vi burde også være i stand til at tilsidesætte den systemdefinerede MAXDOP for automatiske statistikopdateringer, men indtil videre ville jeg være glad for mere kontrol over manuel statistikstyring. Anmodningen er fanget i følgende Connect-element:

  • Forbind #628971:Tilføj MAXDOP-parameter til opdatering af statistik

Lad forespørgselsoptimeringsværktøjet se statistikker på partitionsniveau

Erin Stellato har blogget om fordelene ved inkrementel statistik her, men ramte virkelig hovedet på sømmet om dets problemer i dette indlæg:Incremental Statistics are NOT used by Query Optimizer. Læs venligst det igennem og stem og kommenter det element, jeg lige har oprettet (jeg kan ikke tro, at jeg aldrig har bemærket, at der ikke allerede eksisterede en DCR for dette):

  • Forbind #2010834 :Optimizer bør faktisk *bruge* statistik pr. partition

Autostatistik bør tage højde for antallet af rækker i et filtreret indeks/stat

I øjeblikket er det at stole på automatiske opdateringer til filtrerede indekser og statistikker som at vente på Godot – algoritmen bruger antallet af rækker i tabellen, når den bestemmer churn-tærsklen, ikke antallet af rækker i indekset. Det betyder, at de fleste filtrerede indekser – og faktisk de mest nyttige filtrerede indekser – vil aldrig blive opdateret automatisk. (Jeg taler om det her, og Kimberly Tripp taler om det her og her. Jeg er sikker på, at andre også har blogget om det.) Jeg synes, det er på tide, at dette ændres – hvis du er enig, så stem og kommenter på Joe Sacks emne (titlen angiver filtreret statistik, men den vedrører virkelig begge dele):

  • Forbind #509638 :Foreslår ændring af filtrerede statistikopdateringer

  1. System.Data.OracleClient kræver Oracle-klientsoftware version 8.1.7

  2. Problemet med vinduesfunktioner og visninger

  3. Hierarkisk liste over triggerhændelsestyper i SQL Server 2017

  4. Postgres tabel kolonne navn begrænsninger?