Jautājums uz ribas – lēns selekts, ko nu?

Ir šāda datu bāze (pieraksts nosacītā sintaksē):

Abonents (AbonentsNr int, Vards varchar(20), Uzvards varchar(20)) primary key (AbonentsNr);
Izdevums (IzdevumsNr int, Nosaukums varvhar(255), Tematika varchar(50)) primary key (IzdevumsNr);
Abonements (AbonementsNr int, AbonentsNr int, IzdevumsNr int, DatumsNo date, DatumsLidz date) primary key (AbonementsNr), foreign key (IzdevumsNr) references Izdevums (IzdevumsNr), foreign key (AbonentsNr) references Abonents (AbonentsNr)

Abonents 100 000 ierakstu, Izdevums 100 ierakstu, Abonements 500 000 ierakstu.

Sistēma izpilda SQL pieprasījumu:

SELECT * FROM Abonents WHERE AbonentsNr in (SELECT AbonentsNr From Abonements, Izdevums WHERE Abonements.IzdevumsNr = Izdevums.IzdevumsNr AND Izdevums.Tematika=”Lauksaimniecība”)

Pieprasījums izpildās lēni. Ko nu?

P.S. šis raksts nav tāpēc, ka personīgi man būtu problēmas atrisināt šāda veida uzdevumus. Vienkārši – interesē, kādus risinājumus komentāros piedāvās lasītāji.

Un šeit ir manas solītās pārdomas (pievienotas 13.01.2012) – kāds būtu mans domu gājiens.

1) indeksi (sk. Jāņa komentāru zemāk). Iemesls, kāpēc kā pirmo lieku indeksus, nevis acīmredzami nepieciešamo selekta optimizēšanu, ir šāds: lai uztaisītu vienkāršu indeksu, nevajag ne daudz prāta, ne daudz laika, tāpēc šis ir risinājums – aizbāznis, kurš var atvieglot dzīvi ĀTRI.

2) selekta optimizēšana. Daži no komentāros minētajiem variantiem (Gatis, Kaspars, Jānis) ir tīri ok.

select distinct a.*
from Izdevums i
inner join Abonements ab on ab.IzdevumsNr = i.IzdevumsNr
inner join Abonents a on a.AbonentsNr = ab.AbonentsNr
where Izdevums.Tematika = ”Lauksaimniecība”

Un ātri izdarāmais:

… WHERE AbonentsNr in (SELECT AbonentsNr From … )” vietā rakstīt WHERE EXISTS (SELECT … ). Jo ar EXISTS tiek meklēts pirmais ieraksts, kas atbilst kritērijam, kamēr ar AbonentsNr in … vispirms ir jāatlasa visi ieraksti, kas atbilst tam.

Arī šis Jāņa man patika:

Uztaisi klasifikatoru “Tematika”, un Izdevums.Tematika aizvieto ar Izdevums.TematikaNr, kuru taisi par foreign.key. Rezultātā nemeklē pēc teksta ”Lauksaimniecība”, bet pēc iepriekš atlasīta Tematika.Nr.

Un Jāņa doma par materializēto skatu.

2 ar pusi) tabulas iespējamā pārslodze – varbūt tajā ir neaktuāli dati, kurus vienreiz vajag aizarhivēt prom, un varbūt vajag padomāt par informācijas dalīšanu pa vairākām tabulām, piemēram, līdzko pienācis DatumsLidz, tā ieraksts ar kāda procesa palīdzību tiek automātiski pārnests uz vēsturisko datu tabulu.

2 ar trim ceturtdaļām): pārliecināt klientu, ka viņam patiesībā šāda vaicājuma rezultātu nemaz nevajag :-) :-) :-) (reveranss Gintam)

3) servera jauda – atmiņa, ātrums, kāds ir, ko var uzlabot?

3 ar pusi) pārbaudīt, kāds ir datu pārsūtīšanas ātrums savienojumā + datu attēlošanas uz ekrāna ātrums. Varbūt pats selekts izpildās ātri, taču problēma ir tur, ka tehnika rada sajūtu, ka tas izpildās lēni?

3 ar trim ceturtdaļām) izvietot tabulas uz dažādiem diskiem, tādējādi paātrinot fizisko nolasīšanu. Jā, šāds risinājums vairāk ir apsverams lielākiem datu apjomiem, taču kā variantu pieminu.

 4) datubāzes iespējamā pārslodze – izvērtēt iespēju samazināt datu apjomu vai pieprasījumu apjomu citās tabulās.

4 ar pusi) Ja esošā DBVS, par spīti veiktajiem pasākumiem ir par vāju, domāt par iespēju apstrādāt datus ar jaudīgāku DBVS.

Par iesūtītajiem komentāriem – sirsnīgs paldies visiem, kuri atsaucāties. Godīgi – mani sajūsmināja doma, ka par tabulas primāro atslēgu miera vējos tiek pieļauta iespēja, ka tā varētu būt telefona numurs :-). Un arī otrādi – ka lauku AbonentsNr int primarykey – var izlasīt kā telefona numuru ne brīdi nenošauboties :-) Mācība priekš manis: citreiz piemēros saukt par Id, nevis Nr. Izlasīju un pasmaidīju, ka dažreiz sistēmanalītiķis не читатель, sistēmanalītiķis писатель. Viens otrs komentārs atgādināja pasaki man savu problēmu  un es pateikšu, kāpēc tā nav atrisināma.

Lielākā daļa komentāru bija par paša selekta optimizēšanu vien, nepiesaucot iespējamos ārējos apstākļus. Ja šis būtu eksāmens, es teiktu – draugi, izkāpsim ārpus kastītes! Bet šis nebija eksāmens. Ceru, ka arī jums bija interesanti. Oficiālāku literatūru par dažādām optimizēšanām gūglējiet paši – papilnam.