liviu.costea:Am o tabela (tabela_mea) cu peste 2 mil inregistrari si care are un index clustered (pe o coloana identity). Mai are un index pe o coloana (coloana_x), iar densitatea e de 0,79. Am doua cazuri:
Cazul 1:
SELECT * FROM tabela_mea WHERE coloana_x = 1
In cazul asta la index seek imi da estimated number of rows 1,2 ceea ce consider eu ca e ok.
Cazul 2:
DECLARE @val_x int
SET @val_x = 1
SELECT * FROM tabela_mea WHERE coloana_x = @val_x
Aici la index seek imi da 10,75 estimated rows.
Acum stiu ca al doilea caz e un singur batch si nu poate sa vada valoarea parametrului si imi da o valoare generala. Dar totusi de unde valoarea asta de 10,75. Eu credeam ca se uita la selectvitatea indexului (care e 1,2).
Is deschis la orice varianta / explicatie. 
Multumesc.
Ca fapt divers, dacă doreşti ca SQL Server să utilizeze în al doilea caz acelaşi plan de execuţie pentru interogarea
SELECT ... WHERE coloana_x ... ca şi cel din primul caz (este foarte probabil ca planurile de execuţie în cele două cazuri să fie diferite) o soluţie simplă presupune utilizarea - începând din SQL Server 2005 - a clauzei OPTION OPTIMIZE FOR astfel:
1
2
3
4
|
| SELECT *
FROM tabela_mea
WHERE coloana_x = @val_x
OPTION (OPTIMIZE FOR(@val_x = 1)) |
Deşi variabila @val_x poate lua diverse valori, planul de execuţie utilizat va fi cel optimizat pentru @val_x = 1.
BOL URL: ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/66fb1520-dcdf-4aab-9ff1-7de8f79e5b2d.htm
BOL URL: ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/bfc97632-c14c-4768-9dc5-a9c512f6b2bd.htm