Med kunstig intelligens skaber HP’s nye OmniBook X 14 en unik og skræddersyet brugeroplevelse målrettet dem, der ønsker høj ydeevne og intelligente funktioner
Muligvis kan du også gøre følgende, afhængig af om en cast til varchar(2) tager de to første eller to sidste tegn. Jeg vil tro den tar de to første, go så skulle du kune gøre:
Select * from Vare where cast(Nummer as varchar(2)) = '13'
Det er ingen grund til at konvertere (Cast), når Nummer er VarChar, så det hurtigste vil jeg mene vil være at bruge en LEFT, for at hente de to første tegn. Dette er hurtigere end at bruge LIKE.
En left er under ingen omstændigheder hurtigere end en like og specielt ikke når der skal søges efter noget "der starter med"! En left, right whatever function på venstresiden vil altid resultere i en fulltablescan hvilket gør den rimelig tung :-)
>janus 007: Du har delvist ret. Jeg har testet lidt på en tabel med 141000 records, og execution plan er stort set lig både med like og where. Når jeg lægger et index på det aktuelle tekstfelt som jeg søger på, bruger SQL Server 2005 indexet både ved brug af like og ved brug af where. Jeg har derfor ikke kunne måle den store forskel, men Estimated CPU cost og Estimated I/O cost er lavere ved brug af like i forhold til where.
Den hurtigste forespørgsel vil derfor nok være: Select * from Vare where Nummer = '13%'
Og for til slut at kommentere Jeres diskusion har jeg testet disse tre sætninger: 1.Select * From Vare Where Left (Nummer, TextBox2.Text.Lenght) = @medarbejderId; 2.Select * From Vare Where Nummer Like @medarbejderId%; 3.Select * From Vare Where Nummer = @medarbejderId%;
It mit eksempel er query 1 den hurtigste og samtidig den eneste der i alle Test resultater returnerede det rigtige :-)
lorentsnv-> Når du siger ved brug af like og where, mener du så where som i : Select * from Vare where left(cast(Nummer as varchar(100),2) = '13' ?
Scarface -> Det er godt du finder den sql der lige passer ind i dit scenerie, så er opgaven løst bedst muligt - ingen tvivl om det. At de ikke returnerer det korrekte er nok en anden snak ;-)
Men jeg kan garantere for at et funktionskald på venstresiden vil resultere i fulltablescan, årsagen er at SQL jo ikke kan indexere funktionskaldet, men kun den originale værdi. Hvis tabellen er stor nok til at queryoptimizeren vurderer at indexet er anvendeligt vil en left give et dårligere resultat ligegyldigt hvad.... Men ved små datamængder vil forskellen nok ikke være den store, derfor er det bedste også som du har gjort... nemlig at teste :-)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.