Border și Moment of Time sunt obiecte de aplicație care sunt o combinație a unei date și a unui număr de alți parametri care permit sistemului să specifice limita exactă pentru obținerea datelor din tabelele de registru.
De exemplu, o situație frecventă este prezența mai multor documente într-o secundă - în acest caz, dezvoltatorii folosesc poziția documentului pentru a primi corect reziduurile în procesarea exploatației, deoarece Când utilizați o dată simplă, este posibil ca datele să nu fie corecte.
Cu toate acestea, utilizarea funcției Border și Time Moment poate degrada performanța prin încetinirea cererilor elementare chiar și a tabelelor virtuale.
Să luăm în considerare un exemplu concret.
Ia acumulare registru „PartiiTovarovNaSkladah“ și de a obține de la ea se echilibrează cu selecție pe nomenclatura și depozite.
(în tabelele temporare cu nomenclatura și depozitele de valoare puțin)
Există un indice suplimentar pentru măsurarea Depozitului.
Executăm o interogare cu o valoare diferită pentru parametrul "period":
Executăm aceste interogări de mai multe ori și obținem următoarele rezultate:
Măsurătorile sunt efectuate pentru 3 valori diferite ale "Gradului maxim de paralelism" al serverului MSSQL.
Există opinii diferite cu privire la parametrul MAXDOP. 1C-poreclele tind să instaleze o unitate mai des. Și aici este, de exemplu, vizualizarea DBA, care administrează alte tipuri de aplicații :).
Dar întrebarea este diferită.
În toate cele 4 cazuri, platforma generează aproximativ aceleași interogări cu două părți:
Bilanțul final este obținut prin diferența dintre aceste două tabele.
Odată cu selectarea rezultatelor în termeni de performanță, totul este bine - tabelul are un index cluster cu toate dimensiunile pentru care condițiile de interogare sunt potrivite.
Dar cu eșantionul din tabelul de mișcări există o problemă.
Pentru o condiție cu o poziție a documentului, interogarea arată astfel:
Pentru o condiție cu o dată, interogarea arată astfel:
Evident, în primul caz, interogarea este mai complexă pentru percepția optimizatorului.
Executăm ambele subansamble în Gestionare SQL Server Studio și vedem cum sunt executate:
Statistici I / O și timp de execuție:
Prima interogare (din poziția documentului) a fost executată de 4,5 ori mai lungă decât cea de-a doua și a necesitat o lectură logică de 8 ori mai mare.
Structura este identică, însă parametrii utilizați sunt diferiți.
Pentru prima cerere Seek Predicate, este specificată o singură dată (perioada este mai mică decât 1 mai), iar pentru cea de-a doua se specifică ambele restricții de perioadă.
Soluția problemei:
Dacă aveți o problemă este confirmată, este de dorit la maxim să renunțe la utilizarea limitelor și MomentaVremeni în selectarea perioadei în cererile de tabele virtuale. În cazul în care o astfel de cerere este în proces a documentului, selectarea reziduurilor pentru poziția documentului nu trebuie întotdeauna, dar numai în cazul în care documentul nu este primul în al doilea documentelor și afectează reciproc. În funcție de documentul de intensitate, se poate reduce în mod semnificativ numărul de interogări efectuate parametri nedorite.
De exemplu, atunci când scrieți un document, verificați dacă există intrări în registru într-o anumită secundă înainte de documentul curent pentru aceeași depozit. Dacă nu, selectați reziduurile după dată, dacă da - după poziția documentului:
În același timp, există o variantă de simplificare a solicitării cu poziția documentului, care va permite eliminarea acestei probleme. Din păcate, numai dezvoltatorii platformei pot face acest lucru.
Am descris această situație și opțiunea de optimizare în cadrul conferinței partenere.
Cine are acces - Voi fi recunoscător pentru "+1" în acel subiect.
Articole similare
Trimiteți-le prietenilor: