Optimering af SQL

Med fare for at påpege det åbenbare. Henter du virkelig "select *" eller er det bare for at spare plads her?

Er der text, image eller lignende tunge felter i tabellen?

Du kan overveje at samle de to bits i et heltalsfelt i stedet. Det at de samles og at der desuden kan laves indeks på felterne må speede tingene meget op. Ulempen er bitoperationen før selecten:

Felterne:
  Exported: bit (Entered = Exported ikke?)
  Deleted: bit

erstattes af
  State int

Hvis Deleted flaget er bit 0 og Exported bit 1 osv, kan du samle op til 31 flag i State feltet.

  SELECT * FROM [Data] WHERE [DataId]=58 AND [State]=2 <-- ..0000010b

Du kan prøve at kigge lidt på de værktøjer der nævnes i nedenstående opslag:

  http://www.eksperten.dk/spm/805050

Hej hrc

Kikker lige på det, nej grunden for at jeg bruger * er egentlig bare, at begge SQL med resultat på 10000 burde tage den samme tid, uden hensyntagen til antal felter i resultat.

Jeg kan ikke huske om det kan lade sig gøre eller ej, at indexere et bit felt, ment det giver oftest ikke ret meget mening. Du skal huske, at når du laver en vanlig index (ikke et clustred index), så skal den førs læse i index tabellen, og finde ud af hvilke fysiske records den skal hente, og så skal den over i den fysiske tabel og hente de records. Hvis du laver index på et enkelt bit felt, vil det være hurtigere at lave table scan på hele den fysiske tabel. Hvis du derimod laver index på en kombination af felter, hvor nogle af disse er bit felter, kan det godt forholde sig anderledes. Men husk at indexet kun fungerer, hvis du har de første felter i indexet med som filter i den forespørgsel. Effekten af indexet afhænger således af hvor mange af felterne i indexet, talt fra starten af 'rækkefølgen', som du har med i din Where.

Du kan have en clustered index pr tabel, og data bliver fysisk lagret i den rækkefølge din clustered index angiver. Fordelen er, at den ikke skal læse både i index tabel, og fysisk tabel.

Et alternativ du kan vurdere, hvis du ofte forespørger kun nogle få felter, er at includere alle dine felter i dit index. Således behøver serveren ikke at gå over i den fysiske tabel, når den har søgt igennem indexet, da alle felter du spørger efter, er indehold i index tabellen.

I stedet for bit-felter, bør du bruge et tinyint-felt. Fylder det samme i tabellen og kan indekseres.
Jeg kunne forestille mig, at et alm. indeks på eksported feltet vil gøre en eksportoperation kører meget hurtige i takt med at der kommer flere data i tabellen.
Ellers kan det ikke anbefales at lægge indeks på netop disse felter.