Kan denne stored procedure optimeres yderligere?

Har du prøvet:

SELECT DISTINCT item FROM [dbo].tabel WHERE aktiv = 1 AND acceptvote = 1 ORDER BY item ASC

?

Altså med DISTINCT uden GROUP BY

Ja, men det virkede som om det var langsommere. Har desuden også læst at man skal holde sig fra at bruge DISTINCT.

Er der index på aktiv og acceptvote ?

De er af typen "bit"... kan man sætte index på dem? Hvis ja - hvordan så?

Nej det kan man ikke.

Hvor lange er dine records ?

Med kun 13000 records er der jo en pæn chance for at alle data hentes
fra cache og så bliver det dæleme svært at påvise nogen nævneværdig forskel
i hastighed næsten uanset hvad man gør.

Hvor lange? Selve feltet, som er det eneste der bliver hentet i select-sætningen, er på max 50 tegn.

Jeg tænkte på hele recorden altså med alle felter.

Der er 26 kolonner hvoraf der er blandet ntext, int og nvarchar-typer.

Fjern evt. din order by og se om det går hurtigere.

Og hvad taler vi om i execution time?

Udover det så vær sikker på at din select bruger indexet, bare fordi du har oprettet det er jo ikke ensbetydende med anvendelsen ;O)

Jeg kan ikke fjerne order by, da det skal sorteres.
Til tider kan execution time komme helt op på 3 sekunder, når der er mange på samme tid.
Hvordan kan jeg sikre mig at select'en bruger indexet?

Hvis du laver et view ud af din select statement, og lader din spGetItems kalde viewet, og (her kommer det smarte) sørger for at lave et index på dit view. Så kører det hurtigt.

Prøv at lave ét indeks der dækker kolonnerne ITEM, AKTIV og ACCEPTVOTE (i nævnte rækkefølge) - det burde give en performance boost.

Et indekseret view som hspoulsen foreslår virker også, men har et par bivirkninger. Læs i BOL om din app kan leve op til de begrænsinger der er - og vær opmærksom på, at opdaterering i tabellen bliver langsommere når der ligger et indekseret view ovenpå.

Trer,
Skal felterne ikke være i modsat rækkefølge? AcceptVote, Aktiv og derefter Item.
Hvordan kan det være at opdateringen bliver langsommere, end når dit index tilføjes?
Det har jeg ikke kunnet se.
Men det er rigtigt at der er nogle begrænsninger.

-- =============================================
-- Create schemabinding view
-- =============================================
IF EXISTS (SELECT TABLE_NAME
      FROM  INFORMATION_SCHEMA.VIEWS
      WHERE  TABLE_NAME = N'testhsp')
    DROP VIEW testhsp
GO

CREATE VIEW testhsp WITH SCHEMABINDING
AS
  SELECT item,  count_big(*) 'Antal'
  FROM [dbo].tabel
  WHERE aktiv = 1 AND acceptvote = 1
  GROUP BY item
  --ORDER BY item ASC
GO
 
-- =============================================
-- Create index basic template
-- =============================================
CREATE UNIQUE CLUSTERED INDEX testhsp1
ON db.dbo.testhsp
    (item)
GO
CREATE Procedure spGetItems

As
    SELECT item
    FROM [dbo].testhsp
    ORDER BY item ASC
GO

hspoulsen> Et indekseret view er i virkeligheden en kopi af data - altså en ekstra tabel. Det betyder, at når du opdatererer base-tabellen, så skal den finde og opdatere de tilsvarende data i viewet.  Det er en tung process.

Et alm. indeks på tabellen fungerer lidt anderledes - der bliver der først opdateret når 20% data har ændret sig - og opdateringen sker ved nogle statistiske beregninger hvor den ved store tabeller (over 8 mb) kun tager et repræsentativt udsnit af data med.

Mht rækkefølgen i det sammensatte indeks - du kunne godt have noget der; Afhængigt af data kan det godt være at en omvendt rækkefølge vil give bedre performance - så det må en test afgøre. En "nem" løsning ville være at lave begge indeks og lade query optimizeren selv vælge hvad den anvender, det rigtige ville være at teste.

Fordelen ved det sammensatte indeks er i øvrigt, at SQL Server så kan nøjes med at læse indeks og man så undgår læsning af selve tabel-data - dvs. færre i/o og bedre performance.

En anden ting - check evt. med DBCC SHOWCONTIG om tabellen er fragmenteret (scandensity skal være høj og antal extentsswap lig med antal extents i tabellen). Er den fragmenteret, så defragmenter den med DBBC REINDEX

Troels> Tak for det. Det betyder at hvis data stort set er read-only, i forhold til antal kald til spGetItems, så er mit forslag ok. Hvis ikke, så skal man istedet kigge på sammensatte indeks. Det er godt at vide.