Limitele numărului de rânduri dintr-o tabelă SQL Server

Există limite grele asupra numărului de rânduri într-un tabel într-o tabelă de server sql? Sunt sub impresia că singura limită se bazează pe stocarea fizică.

În ce moment performanța se degradează semnificativ, dacă nu, pe tabele cu și fără index. Există vreo practică comună pentru mesele foarte mari?

Pentru a oferi o cunoaștere a domeniului puțin, intenționăm să folosim un tabel de audit care va loga modificările câmpurilor pentru toate tabelele dintr-o bază de date și se întreabă ce tipuri de pereți s-ar putea întâmpla împotriva.

4

4 răspunsuri

În plus față de toate cele de mai sus, care sunt recomandări grozave, m-am gândit că aș da un context mai mult pe punctul de index/performanță.

După cum sa menționat mai sus, nu este posibil să se dea un număr de performanță, în funcție de calitatea și numărul indiciilor dvs. performanța va fi diferită. De asemenea, depinde de ce operațiuni doriți să optimizați. Trebuie să optimizați inserțiile? sau sunteți mai preocupat de răspunsul la interogare?

Dacă sunteți cu adevărat preocupat de viteza de inserare, partiționarea, precum și o analiză FOARTE atentă index va fi cheia.

Recomandarea tabelului separat de Tom H este, de asemenea, o idee bună.

2
adăugat

BrianV este corect. Este greu să dai o regulă, deoarece variază drastic pe baza modului în care vei folosi tabelul, cum este indexat, coloanele reale din tabel etc.

În ceea ce privește practicile obișnuite ... pentru mesele foarte mari, puteți lua în considerare împărțirea. Acest lucru ar putea fi util în special dacă descoperiți că pentru jurnalul dvs. vă interesează de obicei schimbările din ultima lună (sau 1 zi, 1 săptămână, 1 an, oricare). Ar putea apoi să arhivați porțiuni mai vechi ale datelor, astfel încât acestea să fie disponibile dacă este absolut necesar, dar nu vor fi în cale, deoarece aproape că nu veți avea nevoie de ea.

Un alt lucru care trebuie luat în considerare este să aveți un tabel de jurnal separat pentru fiecare tabelă reală, dacă nu intenționați să faceți acest lucru. Utilizând o singură tabelă de jurnal, este foarte dificil să lucrați cu ea. De obicei, trebuie să înregistrați informațiile într-un câmp de text liber, care este dificil de interogat și de procesat. De asemenea, este dificil să te uiți la date dacă ai un rând pentru fiecare coloană care a fost schimbat pentru că trebuie să faci o mulțime de conexiuni pentru a privi schimbările care au loc simultan.

2
adăugat

Este adevărat că numărul de rânduri este limitat de spațiul de stocare disponibil.

Este greu să dai numere, deoarece depinde în mare măsură de hardware-ul serverului, configurația și cât de eficiente sunt interogările tale.

De exemplu, o instrucțiune simplu select va rula mai repede și va afișa o degradare mai mică decât o căutare completă sau proximitate ca numărul de rânduri crește.

2
adăugat

Cu tabelele de audit, o altă abordare este de a arhiva datele o dată pe lună (sau săptămână, în funcție de cantitatea de date pe care le puneți în ea) sau cam asa ceva. În acest fel, dacă trebuie să recreați unele modificări recente cu datele proaspete, se poate face împotriva tabelelor mai mici și astfel mai repede (recuperarea din tabelele de audit este aproape întotdeauna o sarcină urgentă pe care am găsit-o!). Dar aveți în continuare datele avialabile în cazul în care vreți să vă întoarceți mai departe la timp.

1
adăugat