Alle disse er funktionelt ækvivalente. Selv adskillelsen mellem WHERE-sætning og JOIN-betingelse vil ikke ændre resultaterne, når man arbejder helt med INNER joins (det kan have betydning med OUTER joins). Derudover bør alle disse arbejde ud i nøjagtig den samme forespørgselsplan (effektivt nul ydeevneforskel). Den rækkefølge, du inkluderer elementer i, er ingen betydning . Forespørgselsmotoren er fri til at optimere, da den finder bedst egnet inden for forespørgslens funktionelle specifikation. Selv når du identificerer specifik adfærd med hensyn til orden, bør du ikke regne med det. Specifikationen giver mulighed for, at morgendagens patch kan ændre dagens adfærd på dette område. Husk:Hele pointen med SQL er at være sæt-baseret og deklarativ :du fortæller databasen hvad du vil have det til at gøre, ikke hvordan du vil have det til at gøre det.
Nu hvor korrekthed og ydeevne er af vejen, er vi nede til spørgsmål om stil:ting som programmørproduktivitet og læsbarhed/vedligeholdelse af koden. I den forbindelse er mulighed #4 på listen langt det bedste valg, med #3 det næstbedste, især når du begynder at komme ind i mere komplicerede forespørgsler. Brug bare ikke A,B syntaks længere; det har været forældet siden 1992-versionen af SQL-standarden. Skriv altid hele INNER JOIN (eller LEFT JOIN /RIGHT JOIN /CROSS JOIN osv.).
Alt det sagt, selvom rækkefølge ikke betyder (eller i det mindste burde) ikke noget for ydeevnen, finder jeg det nyttigt, når jeg skriver SQL, at bruge en konvention i min tilgang, der dikterer rækkefølgen. Dette hjælper mig med at identificere fejl eller falske antagelser senere ved fejlfinding og fejlfinding. Denne generelle vejledning, som jeg forsøger at følge, er at opføre sig, som om rækkefølgen betyder noget, og så med det i tankerne forsøge at holde det arbejdssæt af hukommelse, der kræves af databasen for at opfylde forespørgslen så lille som muligt, så længe som muligt:start med mindre borde først og kom derefter til de større; Når du overvejer tabelstørrelse, skal du tage højde for betingelser i WHERE-sætningen, der matcher et indeks; foretrækker de indre sammenføjninger før de ydre, når du har valget; angiv joinbetingelser for at favorisere indekser (især primære/klyngede nøgler) først, og andre betingelser på joinforbindelsen derefter.