crystyp: Am executat sintaxa
Table 'StatusHistory'. Scan count 3, logical reads 38899, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Package'. Scan count 3, logical reads 24920, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Citest 39k pagini din StatusHistory si 25k pagini din Package ca sa produci 1 (unu) row. A durat doar 8 secunde ca totul era in memorie, cached (0 physical reads). Dureaza probabil mult cind cache-ul e cold si chiar trebuie sa citeasca.
Query-ul tau poate fi rescris sa faca seek, nu scan, daca schimbi inner-select-ul in join, adaugi un index pe pac_parcelNumber in package, si un index pe (sth_fk_sat, sth_number) cu include (sth_fk_sge) pe status_history. Evident, fara sa stiu ce face resytul aplicatiei nu pot sa spun daca asta e solutia
corecta sau nu, dar absolut trebuie sa elimini SCAN-ul si sa se faca SEEK.
Rolul tau vis-a-vis aceasta baza de date si aplicatie care e? dba, admin, developer?
http://rusanu.com