Vaicājuma statistika

Raksta mērķis mudināt paspēlēties ar "Statistics IO" tiem, kas to vēl nav darījuši.
Vaicājumu optimizēšana ir diezgan sarežģīta lieta un katrs gadījums ir pilnīgi savādāks. Tas, ko izdaru pirmām kārtām saskaroties ar „Lēno” vaicājumu ir- mēģinu lokalizēt problēmu nosakot, kuru tabulu tas lasa visvairāk.
Tas ko daru- izpildu „Lēno vaicājumu” Management studio vidē uzstādot „Set Statistics IO on”.

Ilustrācijai izmantošu mākslīgu piemēru (kāpēc tāda dīvaina funkcija- to pēc tam):

create table dbo.PiemeraTab
(
AtslegaID int identity(1,1) primary key,
LigumaNr nvarchar(12)
)
Go
insert into dbo.PiemeraTab (LigumaNr) values ('LVSQLBLOG001')
insert into dbo.PiemeraTab (LigumaNr) values ('LVSQLBLOG002')
insert into dbo.PiemeraTab (LigumaNr) values ('LVSQLBLOG003')
Go
Create Function dbo.PiemeraFunkcija
(
@Cipars int
)
Returns int
As
Begin
Return (
Select count(*) From dbo.PiemeraTab
Where Cast(Right(LigumaNr,3) as int) = @Cipars)
End

Pēc tam „Lēno vaicājumu” izpildu:

set statistics io on
select *, dbo.PiemeraFunkcija(2) from dbo.PiemeraTab
set statistics io off

Alternatīvs veids, kā panākt lai tiktu uzrādīta šī informācija- labā poga vaicājuma izpildes logā Management studio, izvēlamies „Query Options”, tālāk „Advanced” un ieliekam ķeksīti pretī „Set Statistics IO”

Iegūstu rezultātu (messages tab-lapiņā):

(3 row(s) affected)
Table 'PiemeraTab'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

No rezultāta es varu secināt, ka lasīta tiek „PiemeraTab”, kura tiek pārskatīta vienu reizi (scan count), notikusi 2 lapu nolasīšana (2x8kb) no operatīvās atmiņas (jo logical reads = 2, bet physical reads = 0. Logical reads ir svarīgāks). Pārējie lielumi šobrīd netiek apskatīti- tiem arī daudz retāk ir svarīgi pievērst uzmanību (par read-ahead reads var mazliet lasīt rakstā Indeksu fragmentācija).

Šajā gadījumā gan nekādus prātīgus secinājumus no šī nevar izdarīt, tomēr ja vaicājums būtu sarežģītāks, iekļaut skatus, kas lasa datus no daudzām tabulām- šie rezultāti dotu priekštatu, kādā virzienā skatīties tālāk. Šie rezultāti ir arī daudz objektīvāki, kā vaicājuma izpildes laiks, kas atkarīgs no daudziem citiem faktoriem- tīkla ātruma, citu lietotāju darbībām datu bāzē, ...

Parasti (bet ne vienmēr) daudz lasīšanas operāciju no kādas tabulas norāda, ka būtu vērtīgi apskatīt šīs tabulas indeksus- vai tie ir pietiekami (piemēram- indeks uz FK kolonas), apskatīt kā šī tabula tiek sieta ar citām tabulām. Skatīties izveidoto izpildes plānu.

Vaicājumā funkcija tika iekļauta, jo šai statistikai ir „āķis”- tā neatgriež rezultātu par darbībām, kas notiek funkcijā. Ja paskatītos read operāciju skaitu ar SQL Profiler palīdzību, rezultāti atšķirtos.

Varētu rasties jautājums, kāpēc vienmēr neskatīties statistiku SQL Profailer? Pirmkārt- tas ir ilgāk- jāliek filtri, jālaiž programm utt, otrkārt, tur netiek parādīts cik daudz tiek lasīts no konkrētas tabulas. Bet ir citi plusi- var iegūt daudz dažādu cita veida informāciju.

Un noslēgumā lai savāktu visu aiz sevis:

drop table dbo.PiemeraTab
drop function dbo.PiemeraFunkcija

PS Rakstā ir daudz iztrūkstošas informācijas. Šeit varētu daudz saistīto lietu apskatīt- sākot ar to kāpēc nolasa divas lapas informācijas, ja skaidri redzams, ka datu tabulā ir daudz mazāk nekā 16 kb un beidzot ar to- kāda informācija ir iegūstama ar SQL Profiler palīdzību...