Variabila de sistem Max_Seeks_For_Key din MySQL controlează un prag legat de procesul de luare a deciziilor Optimizer atunci când alegeți dacă utilizați o scanare a indexului sau o scanare completă a tabelului. Setarea max_seeks_for_key prea mare are mai multe riscuri care pot afecta performanța și eficiența întrebărilor într -o bază de date MySQL.
max_seeks_for_key reprezintă numărul maxim asumat de cheie care caută optimizatorul se așteaptă atunci când căutați un rând pe baza unei chei de index. În mod implicit, această valoare este extrem de mare (pe un sistem pe 64 de biți, este de obicei setată la 18.446.744.073.709.551.615). Aceasta înseamnă că optimizatorul nu se va limita în a presupune cât de scumpă poate fi căutarea cheie de către un index.
Când MAX_SEEKS_FOR_KEY este setat foarte mare, optimizatorul tinde să prefere scanările de tabel decât scanările de index, în special în cazurile în care cardinalitatea unui indice (numărul estimat de valori unice într -un index) este relativ scăzut. Acest lucru poate duce la mai multe consecințe nedorite:
1.. Planuri de interogare suboptimale:
Cel mai semnificativ risc de un mare max_seeks_for_key este că optimizatorul de interogare poate alege scanări complete de tabel în loc de scanări de index mai eficiente. Scanările complete de tabel citesc fiecare rând din tabel secvențial, ceea ce poate duce la costuri mai mari de I/O dacă tabelul este mare, iar interogarea are nevoie doar de un subset mic de rânduri. Acest lucru duce la timpii de execuție mai lente în comparație cu utilizarea unei scanări index adecvate.
2.. Utilizarea crescută a resurselor și latența:
Scanările complete de tabel consumă adesea mai multe resurse I/O de disc, deoarece fiecare rând din tabel trebuie examinat. Acest lucru poate contribui la încărcarea generală a sistemului, poate crește latența pentru întrebări și poate scădea randamentul pentru serverul MySQL, în special sub concordanță ridicată a utilizatorilor sau cu seturi de date foarte mari.
3. Performanță slabă pe mese mari:
Deoarece scanările complete necesită citirea întregului tabel, setarea max_seeks_for_key, impact prea mare performanță negativ pentru tabelele mari cu multe rânduri. Interogările care ar trebui să folosească în mod ideal indexurile pentru a filtra rapid rândurile în schimb suportă durate de scanare îndelungate, degradând receptivitatea aplicației.
4. Comportament inconsistent în cadrul întrebărilor:
Deoarece max_seeks_for_key se aplică la nivel global, creșterea valorii sale afectează toate întrebările de pe server. În timp ce unele întrebări ar putea beneficia de scanări complete, multe altele optimizate pentru indexuri ar putea să funcționeze mai rău. Acest lucru aduce o imprevizibilitate și performanțe de interogare inconsistente, necesitând experimentarea și reglarea și reglarea specifică interogării atente și continue.
5. Eșecul de a folosi în mod eficient cardinalitatea indexului:
Cardinalitatea indexului (estimarea valorilor distincte în index) este esențială pentru deciziile MySQL Optimizer. Dacă max_seeks_for_key este setat prea mare, optimizatorul penalizează scanările indexului, presupunând că ar putea necesita căutări de cheie mai scumpe decât o fac, chiar și atunci când ar trebui să se folosească logic indici de cardinalie înaltă. În consecință, optimizările bazate pe index sunt subutilizate sau ignorate.
6. Statistici înșelătoare de optimizator:
Optimizatorul depinde de statistici precum cardinalitatea indexului și costurile asociate căutărilor de rânduri. Când max_seeks_for_key maschează costul real, fiind excesiv de permisiv, poate determina optimizatorul să judece greșit costul căilor de acces, afectând precizia totală a modelului de costuri a optimizerului.
7. Dificultate probleme de rezolvare a problemelor de performanță:
Deoarece max_seeks_for_key poate interacționa în moduri complexe cu statistici de index și planuri de interogare, faptul că se poate stabili prea sus poate face diagnosticul interogărilor lente mai dificile. Poate duce la situații în care indici de reglare sau rescriere nu oferă îmbunătățiri preconizate, deoarece presupunerile fundamentale ale costurilor în Optimizer rămân înclinate.
Rezumatul riscurilor: Setarea Max_Seeks_For_Key Prea mare cauzează optimizatorul MySQL să favorizeze scanările complete ale tabelului în loc de scanări de index, ceea ce duce la timp mai lent de execuție, creșterea CPU și I/O, utilizarea ineficientă a indexurilor, performanța degradată pe tabele mari, comportamentul de interogare inconsistent, estimările de costuri greșite de către optimizator și provocări în ceea ce privește reglarea performanței.
Aceste riscuri evidențiază de ce multe DBA aleg să reducă max_seeks_for_key la un nivel mai moderat (cum ar fi 1000 sau similar). Scăderea valorii încurajează optimizatorul să prefere utilizarea indexului decât scanările complete atunci când cardinalitatea indexului este peste acest prag, îmbunătățind de obicei viteza de interogare și reducând consumul de resurse pentru sarcini de lucru tipice.
În concluzie, în timp ce un max_seeks_for_key foarte ridicat ar putea părea sigur, deoarece nu restricționează optimizatorul, în practică riscă performanțe slabe de interogare, resurse irosite și latență mai mare din cauza scanării premature de tabel complet, în special pe seturi de date mari care ar trebui indexate eficient.