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

Parameter Sniffing (eller Spoofing) i SQL Server

FYI - du skal være opmærksom på noget andet, når du arbejder med SQL 2005 og lagrede procs med parametre.

SQL Server vil kompilere den lagrede proc's udførelsesplan med den første parameter, der bruges. Så hvis du kører dette:

usp_QueryMyDataByState 'Rhode Island'

Udførelsesplanen vil fungere bedst med en lille stats data. Men hvis nogen vender sig om og løber:

usp_QueryMyDataByState 'Texas'

Udførelsesplanen designet til data på størrelse med Rhode Island er muligvis ikke så effektiv med data på størrelse med Texas. Dette kan give overraskende resultater, når serveren genstartes, fordi den nyligt genererede eksekveringsplan vil blive målrettet mod den parameter, der bruges først - ikke nødvendigvis den bedste. Planen bliver ikke genkompileret, før der er en stor grund til at gøre det, f.eks. hvis statistikker genopbygges.

Det er her forespørgselsplaner kommer ind, og SQL Server 2008 tilbyder en masse nye funktioner, der hjælper DBA'er med at fastlægge en bestemt forespørgselsplan på lang sigt, uanset hvilke parametre der bliver kaldt først.

Min bekymring er, at når du genopbyggede din lagrede proc, tvang du eksekveringsplanen til at omkompilere. Du kaldte det med dit yndlingsparameter, og så var det selvfølgelig hurtigt - men problemet var måske ikke den gemte proc. Det kunne have været, at den lagrede proc blev rekompileret på et tidspunkt med et usædvanligt sæt parametre og dermed en ineffektiv forespørgselsplan. Du har muligvis ikke rettet noget, og du står måske over for det samme problem, næste gang serveren genstarter, eller forespørgselsplanen bliver kompileret igen.



  1. MySQL-fejl 1436:Overløb af trådstak med simpel forespørgsel

  2. Er mysql_real_escape_string() og mysql_escape_string() tilstrækkelige til appsikkerhed?

  3. Prag PostgreSQL Developer Day 2016

  4. SQL-forespørgsel til at sammenligne produktsalg efter måned