Symptomer
Når du fyller ut en tabellvariabel med mange rader og koble den deretter sammen med andre tabeller, kan spørringsoptimaliseringen velger en ineffektiv spørringsplan, som kan føre til treg ytelse for spørringen.
Oppløsning
Når du har installert denne hurtigreparasjonen, kan du aktivere sporingsflagg 2453 å tillate en tabellvariabelen til å utløse ny kompilering nok antall rader som er endret. Dette kan tillate at spørringsoptimaliseringen velger en mer effektiv plan.
Problemet ble først løst i den kumulative oppdateringen for følgende eller / og oppdateringspakker for SQL Server.
Samleoppdatering 3 for SQLServer-2014/en-us/help/2984923
Hver nye kumulative oppdateringen for SQL Server inneholder alle hurtigreparasjonene og alle sikkerhetsreparasjoner som fulgte med den forrige kumulative oppdateringen. Sjekk ut de nyeste kumulative oppdateringene for SQL Server:
Oppdateringspakker er kumulative. Hver nye oppdateringspakke inneholder alle reparasjonene som finnes i tidligere oppdateringspakker, sammen med eventuelle nye reparasjoner. Vår anbefaling er å bruke den nyeste oppdateringspakken, og den nyeste kumulative oppdateringen for denne oppdateringspakken. Du trenger ikke å installere en tidligere oppdateringspakke før du installerer den nyeste oppdateringspakken. Bruk tabell 1 i følgende artikkel for å finne mer informasjon om den nyeste oppdateringspakken og nyeste kumulative oppdateringen:
Hvis du vil ha mer informasjon
Når du bruker en tabellvariabelen i et parti- eller prosedyre, er spørringen kompilert og optimalisert for den første tomme statusen for tabellvariabelen. Hvis denne tabellvariabelen fylles ut med mange rader under kjøring, kanskje tidligere kompilerte spørringsplanen ikke lenger optimal. Hvis du for eksempel spørringen kanskje av sammenføyde en tabellvariabel med en nestet løkke fordi det er vanligvis mer effektivt for lite antall rader. Denne spørringsplanen kan være ineffektiv Hvis tabellvariabelen har millioner av rader. En hash-sammenføyning kan være et bedre valg under slike betingelse. Hvis du vil ha en ny spørringsplan, må det bli kompilert på nytt. I motsetning til andre brukere eller midlertidige tabeller, utløser rad antall endringer i en tabellvariabelen ikke en ny spørring-kompilering. Vanligvis kan du omgå dette med ALTERNATIVET (REKOMPILERING), som har sin egen indirekte kostnad.
Sporingsflagg 2453 gjør at fordelen med ny spørring kompilering uten ALTERNATIVET (REKOMPILERING). Denne sporingsflagg er forskjellig fra ALTERNATIVET (REKOMPILERING) i to primære aspekter.
(1) bruker samme rad antall terskelen som andre tabeller. Trenger ikke spørringen som skal kompileres for hver kjøring i motsetning til ALTERNATIVET (REKOMPILERING). Det vil utløse ny kompilering bare når antall radendringen overskrider terskelen som er forhåndsdefinerte.
(2) ALTERNATIVET (REKOMPILERING) tvinger spørringen til å kikke parametere og optimalisere spørringen for dem. Denne sporingsflagg tvinger ikke parameteren kikke.
Merk denne sporingsflagg må være videre ved kjøretid. Du kan ikke bruke denne sporingsflagg med QUERYTRACEON. Denne sporingsflagg må brukes med forsiktighet, fordi det kan øke antall nye kompileringer spørring som kan koste mer enn besparelser fra bedre spørringsoptimalisering av.
Status
Microsoft har bekreftet at dette er et problem i Microsoft-produktene som er oppført i delen "Gjelder for".
