Configurarea MYSQL pentru Linux. Ce trebuie configurat în mySQL imediat după instalare

Acest articol va acoperi diverse setări MySQL, în principal cele care afectează performanța. Pentru comoditate, toate variabilele sunt împărțite în secțiuni (setări de bază, restricții, setări fir, interogare cache, timpi, buffere, InnoDB). Mai întâi, să clarificăm numele unor variabile care s-au schimbat în versiunea 4 a MySQL, iar pe Internet continuă să se găsească atât variante vechi, cât și noi de nume, ceea ce ridică întrebări.

Deci, în versiunea 4, un număr de variabile au acum finalul _size. Acest lucru se aplică variabilei thread_cache_size și variabilelor din secțiune Tampoane. Și variabila read_buffer_size a fost numită record_buffer înainte de versiunea 4. De asemenea, variabila skip_external_locking din secțiune Setări de bazăînainte de versiunea 4 se numea skip_locking .

Variabilele se împart în două categorii principale: variabile de valoare și variabile de tip flag. Variabilele cu valori sunt scrise în fișierul de configurare ca variabilă = valoare, iar variabilele flag sunt pur și simplu specificate. De asemenea, probabil ați observat că în unele cazuri „-” este folosit în numele variabilelor, iar în altele „_”. Variabilele cu cratima sunt opțiuni de pornire a serverului și nu pot fi modificate în timp ce serverul rulează (folosind SET); variabilele cu caractere de subliniere sunt opțiuni de operare a serverului și pot fi modificate din mers. Dacă vorbim despre o „variabilă de stare” sau se recomandă monitorizarea valorii unei variabile al cărei nume este scris sub forma Variable_Name , atunci ar trebui să rulați cererea SHOW STATUS LIKE „Variable_Name” pentru a obține valoarea acestei variabile, sau uitați-vă la fila de stare din phpMyAdmin, unde vor exista comentarii suplimentare după valoarea acestei variabile.

Acum să începem să descriem variabilele și valorile lor posibile.

Setări de bază

  • actualizări cu prioritate scăzută- această opțiune reduce prioritatea operațiilor INSERT/UPDATE în comparație cu SELECT. Acest lucru este relevant dacă este important să citiți datele mai repede decât să le scrieți mai repede.
  • skip-blocare-externă- optiunea este instalata implicit, incepand cu versiunea 4. Instruieste serverului MySQL sa nu foloseasca blocaje externe atunci cand lucreaza cu baza de date. Blocările externe sunt necesare în situațiile în care mai multe servere lucrează cu aceleași fișiere de date, de ex. au același datadir , care nu este folosit în practică.
  • skip-name-resolve- nu definiți nume de domenii pentru adresele IP ale clienților care se conectează. În acest caz, permisiunile utilizatorului trebuie configurate nu pentru gazde, ci pentru adrese IP (cu excepția localhost). Dacă vă conectați la server doar de pe mașina dvs. locală, atunci nu contează cu adevărat. Pentru conexiunile externe, va accelera configurarea conexiunii.
  • skip-networking- nu utilizați rețeaua, adică nu procesați deloc conexiunile TCP/IP. Comunicarea cu serverul va avea loc exclusiv printr-un socket. Recomandat, cu excepția cazului în care aveți software care utilizează numai TCP/IP pentru a comunica cu serverul.

Restricții

  • bind-adresă- interfața pe care serverul o va asculta. Din motive de securitate, se recomandă să setați acest lucru la 127.0.0.1 dacă nu utilizați conexiuni externe la server.
  • max_allowed_packet- dimensiunea maximă a datelor care pot fi transferate într-o singură solicitare. Ar trebui să o măriți dacă întâlniți eroarea „Pachet prea mare”.
  • max_connections- numărul maxim de conexiuni paralele la server. Măriți-l dacă întâmpinați problema „Prea multe conexiuni”.
  • max_join_size- dezactivează instrucțiunile SELECT care sunt de așteptat să analizeze mai mult decât un număr specificat de rânduri sau mai mult decât un număr specificat de căutări pe disc. Folosit pentru a proteja împotriva interogărilor strâmbe care încearcă să numere milioane de rânduri. Valoarea implicită este de peste 4 miliarde, așa că probabil că veți dori să o reduceți semnificativ.
  • max_sort_length- indică câți octeți de la începutul câmpurilor BLOB sau TEXT să folosiți la sortare. Valoarea implicită este 1024; dacă sunteți îngrijorat de tabelele sau interogările proiectate incorect, ar trebui să o reduceți.

Setări de flux

  • thread_cache_size- indică numărul de fire stocate în cache. După procesarea cererii, serverul nu va termina firul de execuție, ci îl va plasa în cache dacă numărul de fire de execuție din cache este mai mic decât valoarea specificată. Valoarea implicită este 0, creșteți-o la 8 sau imediat la 16. Dacă observați o creștere a valorii variabilei de stare Threads_Created, atunci ar trebui să creșteți în continuare thread_cache_size.
  • thread_concurrency- relevant doar pentru Solaris/SunOS, contrar a ceea ce scriu ei pe Internet. „Spune” sistemului câte fire de execuție trebuie să ruleze simultan prin executarea unui apel de funcție thr_setconcurrency. Valoarea recomandată este dublul sau triplul numărului de nuclee de procesor.

Interogarea în cache

  • query_cache_limit- dimensiunea maximă a unei cereri stocate în cache.
  • query_cache_min_res_unit- dimensiunea minimă a unui bloc stocat în cache.
  • query_cache_size- mărimea cache-ului. 0 dezactivează utilizarea memoriei cache. Pentru a selecta valoarea optimă, trebuie să monitorizați variabila de stare Qcache_lowmem_prunes și să vă asigurați că valoarea acesteia crește ușor. De asemenea, trebuie să rețineți că un cache excesiv de mare va crea încărcare inutilă.
  • tip_interogare_cache- (OFF, CERERE, ON). OFF dezactivează memoria cache, CERERE– memorarea în cache va fi efectuată numai dacă există o directivă SQL_CACHEîn cerere, PE permite stocarea în cache.
  • query_cache_wlock_invalidate- determină dacă datele vor fi preluate din cache dacă tabelul căruia îi aparține este blocat pentru citire.

Vă puteți gândi la un cache de interogări ca la o matrice hash ale cărei chei sunt interogări și ale cărei valori sunt rezultate ale interogării. Pe lângă rezultate, MySQL stochează în cache-ul său o listă de tabele, o selecție din care este stocată în cache. Dacă apar modificări în oricare dintre tabelele din care se află un eșantion în cache, MySQL elimină astfel de mostre din cache. De asemenea, MySQL nu memorează în cache interogările ale căror rezultate se pot schimba.

Când MySQL pornește, acesta alocă un bloc de memorie de dimensiunea query_cache_size . La executarea unei interogări, de îndată ce sunt primite primele rânduri ale rezultatului, serverul începe să le memoreze în cache: alocă un bloc de memorie în cache egal cu query_cache_min_res_unit și scrie rezultatul selecției în acesta. Dacă nu întreaga selecție se încadrează într-un bloc, atunci serverul alocă următorul bloc și așa mai departe. În momentul în care începe scrierea, MySQL nu știe despre dimensiunea eșantionului rezultat, așa că dacă dimensiunea eșantionului scris în cache este mai mare decât query_cache_limit , atunci scrierea se oprește și spațiul ocupat este eliberat, prin urmare, dacă știți în înainte ca rezultatul eșantionului să fie mare, merită să îl executați cu o directivă SQL_NO_CACHE.

Timinguri

  • interactive_timeout- timpul în secunde în care serverul așteaptă activitatea de la o conexiune interactivă (folosind steag CLIENT_INTERACTIVE) înainte de a-l închide.
  • log_slow_queries- spune serverului să înregistreze interogări lungi („lente”) (executând mai mult decât long_query_time). Valoarea este numele complet al fișierului (de exemplu /var/log/slow_queries).
  • timp_de_interogare_lung- dacă cererea rulează mai mult decât timpul specificat (în secunde), atunci va fi considerată „lent”.
  • net_read_timeout
  • net_write_timeout- timpul în secunde în care serverul va aștepta să primească date înainte ca conexiunea să fie terminată. Dacă serverul nu deservește clienții cu canale foarte lente sau instabile, atunci 15 secunde vor fi suficiente aici.
  • wait_timeout- timpul în secunde în care serverul așteaptă ca o conexiune să fie activă înainte de a o termina. În general, 30 de secunde vor fi suficiente.

Tampoane

Toate bufferele au o caracteristică comună - dacă, din cauza setării unei dimensiuni mari a bufferului, datele merg la fișierul de paginare, atunci tamponul va face mai mult rău decât bine. Prin urmare, concentrați-vă întotdeauna pe cantitatea de memorie RAM fizică disponibilă pentru dvs.

  • key_buffer_size- dimensiunea buffer-ului alocat pentru indecși și disponibil pentru toate firele. O setare foarte importantă care afectează performanța. Valoarea implicită este de 8 MB, cu siguranță merită să o măriți. Se recomandă 15-30% din totalul RAM, dar nu are rost să setați mai mult decât dimensiunea totală a tuturor fișierelor .MYI. Urmăriți variabilele de stare Key_reads și Key_read_requests, raportul Key_reads/Key_read_requests ar trebui să fie cât mai mic posibil (< 0,01). Если это отношение велико, то размер буфера стоит увеличить.
  • max_heap_table_size- dimensiunea maximă admisă a unui tabel stocat în memorie (tip MEMORY). Valoarea implicită este 16 MB, dacă nu utilizați tabele MEMORY, setați această valoare la tmp_table_size.
  • myisam_sort_buffer_size- dimensiunea buffer-ului alocat de MyISAM pentru sortarea indicilor când MASA DE REPARATIE sau pentru a crea indici când CREATE INDEX, ALTER TABLE. Valoarea implicită este de 8 MB, ar trebui mărită până la 30-40% din RAM. În consecință, câștigul de performanță va fi atins numai la executarea interogărilor menționate mai sus.
  • net_buffer_length- cantitatea de memorie alocată pentru buffer-ul de conexiune și pentru buffer-ul de rezultate per thread. Bufferul de conexiune va avea dimensiunea specificată, iar tamponul de rezultate va fi de aceeași dimensiune, adică. Fiecare fir va fi alocat de două ori net_buffer_length . Valoarea specificată este o valoare inițială și bufferele vor fi mărite după cum este necesar până la max_allowed_packet . Dimensiunea implicită este de 16 KB. Dacă memoria este limitată sau sunt folosite doar interogări mici, valoarea poate fi redusă. În cazul utilizării constante a interogărilor mari și a memoriei suficiente, valoarea ar trebui mărită la dimensiunea medie de interogare așteptată.
  • read_buffer_size- fiecare fir, când scanează tabelele secvenţial, alocă cantitatea specificată de memorie pentru fiecare tabel. După cum arată testele, această valoare nu trebuie crescută în mod deosebit. Dimensiunea implicită este de 128 KB, încercați să o creșteți la 256 KB și apoi la 512 KB și observați viteza interogărilor precum SELECT COUNT(*) FROM table WHERE expr LIKE „a%”; pe mese mari.
  • read_rnd_buffer_size- relevant pentru interogări cu „ COMANDA PENTRU", adică pentru interogări al căror rezultat trebuie să fie sortat și care accesează un tabel care are indecși. Valoarea implicită este 256 KB, măriți-o la 1 MB sau mai mare dacă memoria permite. Rețineți că valoarea de memorie specificată este, de asemenea, alocată fiecărui thread.
  • sort_buffer_size- fiecare fir care efectueaza operatii de sortare ( COMANDA PENTRU) sau grupuri ( A SE GRUPA CU), alocă un buffer de dimensiunea specificată. Valoarea implicită este de 2 MB, dacă utilizați tipurile de solicitări specificate și dacă memoria permite, atunci valoarea ar trebui mărită. O valoare mare pentru variabila de stare Sort_merge_passes indică faptul că sort_buffer_size trebuie mărită. De asemenea, merită să verificați viteza de execuție a interogărilor precum SELECT * FROM table ORDER BY name DESC pe tabele mari; poate că creșterea buffer-ului va încetini munca (în unele teste, acesta este cazul).
  • table_cache (table_open_cache din versiunea 5.1.3) - numărul de tabele deschise stocate în cache pentru toate firele. Deschiderea unui fișier tabel poate fi o operație destul de intensivă în resurse, așa că cel mai bine este să păstrați tabelele deschise într-un cache. Rețineți că fiecare intrare din acest cache folosește un handle de sistem, așa că poate fi necesar să măriți limita de handle ( ulimit). Valoarea implicită este 64, cel mai bine este să o măriți la numărul total de tabele dacă numărul este în limite acceptabile. Variabila de stare Opened_tables vă permite să urmăriți numărul de tabele care sunt deschise ocolind memoria cache, de preferință păstrând valoarea acestuia cât mai scăzută posibil.
  • tmp_table_size- dimensiunea maximă de memorie alocată pentru tabelele temporare create de MySQL pentru nevoile sale interne. Această valoare este limitată și de variabila max_heap_table_size, așa că în cele din urmă va fi aleasă valoarea minimă între max_heap_table_size și tmp_table_size, iar tabelele temporare rămase vor fi create pe disc. Valoarea implicită depinde de sistem, încercați să o setați la 32 MB și urmăriți variabila de stare Created_tmp_disk_tables, valoarea acesteia ar trebui să fie cât mai mică posibil.

Valorile din fișierul de configurare sunt specificate în octeți, respectiv kilobytes și megabytes trebuie convertiți în octeți.

InnoDB

  • innodb_additional_mem_pool_size- cantitatea de memorie alocată de InnoDB pentru a stoca diverse structuri interne. Dacă InnoDB nu are suficientă memorie, va solicita memorie de la sistemul de operare și va scrie un avertisment în jurnalul de erori MySQL.
  • innodb_buffer_pool_size- cantitatea de memorie alocată de InnoDB pentru stocarea atât a indicilor, cât și a datelor. Înțeles - cu cât mai mult, cu atât mai bine. Poate fi mărită până la dimensiunea totală a tuturor tabelelor InnoDB sau până la 80% din RAM, oricare dintre acestea este mai mică.
  • innodb_flush_log_at_trx_commit- are trei valori valide: 0, 1, 2. Dacă valoarea este egală cu 0 , jurnalul este șters pe disc o dată pe secundă, indiferent de tranzacțiile în curs. Cu o valoare egală cu 1 , jurnalul este șters pe disc cu fiecare tranzacție. Cu o valoare egală cu 2 , jurnalul este scris cu fiecare tranzacție, dar nu este niciodată golit pe disc, lăsând acest lucru în seama conștiinței sistemului de operare. Valoarea implicită este 1, care este cea mai fiabilă setare, dar nu cea mai rapidă. În general, puteți utiliza în siguranță 2, datele pot fi pierdute doar dacă sistemul de operare se blochează și numai în câteva secunde (în funcție de setările sistemului de operare). 0 este cel mai rapid mod, dar datele se pot pierde atât atunci când sistemul de operare se blochează, cât și atunci când serverul MySQL însuși se blochează (totuși, datele sunt doar pentru 1-2 secunde).
  • innodb_log_buffer_size- dimensiunea memoriei tampon. Valoarea implicită este de 1 MB, merită să o măriți dacă știți că va exista un număr mare de tranzacții InnoDB sau dacă valoarea variabilei de stare Innodb_log_waits este în creștere. Este puțin probabil să trebuiască să-l măriți peste 8 MB.
  • innodb_log_file_size- dimensiunea maximă a unui fișier jurnal. Când această dimensiune este atinsă, InnoDB va crea un fișier nou. Valoarea implicită este de 5 MB, mărirea dimensiunii va îmbunătăți performanța, dar va crește timpul de recuperare a datelor. Setați această valoare în intervalul 32 MB - 512 MB în funcție de dimensiunea serverului (judecând subiectiv).

De asemenea, este convenabil să utilizați phpMyAdmin pentru a monitoriza funcționarea serverului; filele sunt de interes StatȘi Variabile. În plus, phpMyAdmin oferă sfaturi privind reglarea anumitor variabile în funcție de parametrii de funcționare a serverului.

La pregătirea articolului, pe lângă documentația oficială și propriul meu cap, s-au folosit următoarele materiale.

  • Traducere

O traducere gratuită a unui articol destul de vechi din MySQL Performance Blog despre ceea ce este mai bine de configurat imediat după instalarea versiunii de bază a mySQL.

Este uimitor cât de mulți oameni instalează mySQL pe serverele lor și îl lasă cu setările implicite.

În ciuda faptului că există destul de multe setări în mySQL pe care le puteți modifica, există un set de caracteristici foarte importante care trebuie optimizate pentru propriul dvs. server. De obicei, după astfel de mici ajustări, performanța serverului crește considerabil.

  • key_buffer_size- o setare extrem de importantă atunci când utilizați tabelele MyISAM. Setați-l la aproximativ 30-40% din RAM disponibilă dacă utilizați numai MyISAM. Mărimea corectă depinde de dimensiunea indicilor, a datelor și a încărcării de pe server - rețineți că MyISAM folosește memoria cache a sistemului de operare (OS) pentru a stoca datele, așa că trebuie să lăsați suficient spațiu RAM pentru date și datele pot ocupa mult mai mult spațiu decât indecșii. Cu toate acestea, asigurați-vă că verificați dacă tot spațiul alocat de directivă key_buffer_size pentru cache, a fost utilizat în mod constant - puteți vedea adesea situații în care 4 GB sunt alocați pentru cache-ul de index, deși dimensiunea totală a tuturor fișierelor .MYI nu depășește 1 GB. A face acest lucru este complet inutil; vei irosi doar resurse. Dacă practic nu aveți tabele MyISAM, atunci key_buffer_size ar trebui să fie setate la aproximativ 16-32 MB - vor fi folosite pentru a stoca în memorie indecși ai tabelelor temporare create pe disc.
  • innodb_buffer_pool_size- o setare la fel de importantă, dar pentru InnoDB, asigurați-vă că îi acordați atenție dacă veți folosi în principal tabele InnoDB, deoarece sunt mult mai sensibile la dimensiunea buffer-ului decât tabelele MyISAM. Tabelele MyISAM, în principiu, pot funcționa bine chiar și cu o cantitate mare de date și cu valoarea standard key_buffer_size, cu toate acestea, mySQL poate fi foarte lent dacă valoarea este incorectă innodb_buffer_pool_size. InnoDB folosește propriul buffer pentru a stoca atât indecși, cât și date, deci nu este nevoie să lăsați memorie pentru cache-ul sistemului de operare - instalați innodb_buffer_pool_sizeîn 70-80% din RAM disponibilă (dacă, bineînțeles, sunt folosite doar tabele InnoDB). În ceea ce privește dimensiunea maximă a acestei opțiuni - în mod similar key_buffer_size- nu vă lăsați dus, trebuie să găsiți dimensiunea optimă, să găsiți cea mai bună utilizare a memoriei disponibile.
  • innodb_additional_mem_pool_size- această opțiune nu are practic niciun efect asupra performanței mySQL, dar recomand să lăsați aproximativ 20 MB (sau puțin mai mult) pentru InnoDB pentru diverse nevoi interne.
  • innodb_log_file_size- o setare extrem de importantă în bazele de date cu operațiuni frecvente de scriere pe tabele, în special cu volume mari. B O Dimensiunile mai mari cresc performanța, dar aveți grijă - timpul de recuperare a datelor va crește și el. De obicei, îl setez la aproximativ 64-512 MB, în funcție de dimensiunea serverului.
  • innodb_log_buffer_size- valoarea standard a acestei opțiuni este destul de potrivită pentru majoritatea sistemelor cu un număr mediu de operațiuni de scriere și tranzacții mici. Dacă sistemul dvs. întâmpină explozii de activitate sau dacă lucrați activ cu date BLOB, atunci vă recomand să creșteți puțin valoarea innodb_log_buffer_size. Cu toate acestea, nu exagerați - o valoare prea mare va fi o risipă de memorie: tamponul este golit în fiecare secundă, astfel încât nu veți avea nevoie de mai mult spațiu decât este necesar în acea secundă. Valoarea recomandată este de aproximativ 8-16 MB, iar pentru bazele de date mici chiar mai puțin.
  • - vă plângeți că InnoDB este de 100 de ori mai lent decât MyISAM? Probabil ai uitat de setare innodb_flush_log_at_trx_commit. Valoarea implicită de 1 înseamnă că fiecare tranzacție UPDATE (sau comandă similară non-tranzacțională) trebuie să golească buffer-ul pe disc, ceea ce necesită destul de mult resurse. Majoritatea aplicațiilor, în special cele care au folosit anterior tabelele MyISAM, vor funcționa bine cu o valoare de „2” (adică „nu ștergeți tamponul pe disc, doar în memoria cache a sistemului de operare”). Jurnalul, totuși, va fi încă șters pe disc la fiecare 1-2 secunde, așa că în cazul unui accident veți pierde maximum 1-2 secunde de actualizări. O valoare de „0” va îmbunătăți performanța, dar riscați să pierdeți date chiar dacă serverul mySQL se blochează, în timp ce setați valoarea la innodb_flush_log_at_trx_commitîn „2” veți pierde date numai dacă întregul sistem de operare se blochează.
  • table_cache- deschiderea meselor poate consuma destul de mult resurse. De exemplu, tabelele MyISAM marchează anteturile fișierelor .MYI ca „în uz curent”. În general, nu este o idee bună să deschideți mesele prea des, așa că cel mai bine este să aveți un cache suficient de mare pentru a vă menține toate mesele deschise. Aceasta utilizează unele resurse ale sistemului de operare și RAM, dar aceasta nu este de obicei o problemă semnificativă pe serverele moderne. Dacă aveți câteva sute de tabele, atunci valoarea de pornire a opțiunii table_cache ar putea fi „1024” (rețineți că fiecare conexiune necesită propriul mâner). Dacă aveți și mai multe tabele sau multe conexiuni, creșteți valoarea parametrului. Am văzut un server mySQL cu valoarea table_cache egal cu 100.000.
  • thread_cache- crearea/distrugerea firelor de execuție este, de asemenea, o operațiune care necesită mult resurse, care are loc de fiecare dată când se stabilește o conexiune și fiecare conexiune este întreruptă. De obicei, setez această opțiune la 16. Dacă aplicația dvs. poate avea salturi în numărul de conexiuni simultane și în funcție de variabilă Threads_Created Dacă observați o creștere rapidă a numărului de fire, atunci ar trebui să creșteți valoarea thread_cache. Scopul este de a preveni crearea de noi fire în timpul funcționării normale a serverului.
  • query_cache_size- dacă aplicația dvs. citește date mult și frecvent și nu aveți un cache la nivel de aplicație, această opțiune poate fi de mare ajutor. Nu setați această valoare prea mare, deoarece menținerea unui cache mare de interogări va fi costisitoare în sine. Valoarea recomandată este de la 32 la 512 MB. Nu uitați să verificați cât de bine este folosit cache-ul de interogări - în unele condiții (cu un număr mic de accesări în cache, adică atunci când aproape nu sunt preluate date identice) utilizarea unui cache mare poate degrada performanța.
După cum puteți vedea, acestea sunt setări globale. Aceste variabile depind de hardware-ul serverului și de motoarele MySQL utilizate, în timp ce variabilele de sesiune sunt de obicei configurate special pentru sarcini specifice. Dacă utilizați mai ales interogări simple, atunci nu este nevoie să creșteți valoarea sort_buffer_size, chiar dacă ai 64 GB de RAM în plus. Mai mult decât atât, valorile mari ale memoriei cache nu pot decât să degradeze performanța serverului. Este mai bine să lăsați variabilele de sesiune pentru mai târziu, pentru reglarea fină a serverului.

PS: instalarea mySQL vine cu mai multe fișiere my.cnf preinstalate, concepute pentru diferite încărcări. Dacă nu aveți timp să configurați manual serverul, atunci de obicei este mai bine să le utilizați decât fișierul de configurare standard, alegându-l pe cel mai potrivit pentru încărcarea serverului dvs.

Parametrii de configurare impliciti din Mysql sunt proiectați pentru baze de date mici care rulează cu sarcini reduse pe hardware foarte modest. Dacă planurile dumneavoastră pentru Mysql se extind dincolo de limitele tabelului cu câteva sute de înregistrări, va trebui cu siguranță să schimbați setările implicite. Procesul de configurare optimă Mysql constă din două părți - configurarea inițială și ajustarea parametrilor în timpul funcționării. Ajustarea parametrilor în modul de funcționare depinde în mare măsură de specificul sistemului dvs. și de monitorizarea acestuia - nu există reguli speciale aici. Există o serie de recomandări pentru configurarea inițială:

MySQL este un sistem gratuit de gestionare a bazelor de date. MySQL este dezvoltat și susținut de Oracle Corporation, care a achiziționat drepturile asupra mărcii împreună cu Sun Microsystems achiziționat, care a achiziționat anterior compania suedeză MySQL AB. Produsul este distribuit atât sub licența publică generală GNU, cât și sub propria licență comercială. În plus, dezvoltatorii creează funcționalități la cererea utilizatorilor licențiați; datorită acestei comenzi a apărut mecanismul de replicare în aproape cele mai vechi versiuni.

Deschideți fișierul de setări mysql, de exemplu:

/etc/mysql/my.cnf

Cei mai comuni parametri cărora ar trebui să le acordați atenție și să îi modificați pentru a se potrivi cerințelor dvs.:

key_buffer_size

Dacă utilizați numai tabele MyIsam, setați această valoare la 30%...40% din toată memoria RAM disponibilă pe server. MyIsam folosește memoria cache a sistemului de operare pentru date, așa că fiți conștienți de faptul că memoria liberă rămasă va fi necesară pentru aceasta. Dacă aveți puține tabele MyIsam și dimensiunea lor totală este mică, lăsați această valoare în 32M.

innodb_buffer_pool_size

Dacă utilizați numai tabele InnoDB, setați această valoare la maximum posibil pentru sistemul dumneavoastră. Buffer-ul InnoDB memorează în cache atât datele, cât și indexurile (și memoria cache a sistemului de operare nu este utilizată), așa că valoarea acestei chei ar trebui setată la 70%...80% din memoria disponibilă.

Dacă serverul dumneavoastră rulează pe Linux sau Unix, nu uitați să setați parametrul innodb_flush_method la „O_DIRECT” pentru a evita stocarea în cache la nivelul sistemului de operare a ceea ce Mysql memorează deja în cache.

innodb_log_file_size

Acordați atenție acestui parametru dacă aveți un număr mare de înregistrări. Cu cât dimensiunea acestei chei este mai mare, cu atât înregistrarea datelor va fi mai eficientă. Dar rețineți că acest lucru va crește timpul de recuperare a sistemului! Acest parametru este de obicei setat la 64M-512M.

innodb_flush_log_at_trx_commit

Acest parametru afectează semnificativ viteza de operare (scriere) a tabelelor innoDB.
Valoarea „1″ înseamnă că orice tranzacție finalizată va șterge sincron jurnalul pe disc.
Valoarea „2″ face același lucru, doar că aruncă jurnalul nu pe disc, ci în memoria cache a sistemului de operare. Această valoare este potrivită în majoritatea cazurilor, deoarece... nu efectuează o operație de scriere costisitoare după fiecare tranzacție. În acest caz, jurnalul este scris pe disc cu o întârziere de câteva secunde, ceea ce este foarte sigur din punctul de vedere al siguranței datelor.
O valoare de „0” va oferi cea mai bună performanță. În acest caz, tamponul va fi golit în fișierul jurnal, indiferent de tranzacții. Setați acest parametru la „0” pe propriul risc, deoarece în acest caz, riscul pierderii datelor crește.

table_cache

Această cheie determină memoria alocată pentru stocarea tabelelor deschise. Dacă aveți câteva sute de tabele, setați această valoare la 1024. Dacă aveți un număr mare de conexiuni, creșteți treptat această valoare, deoarece Pentru fiecare conexiune este stocată o înregistrare separată.

thread_cache

Acest parametru ajută la evitarea operațiunilor de creare/distrugere fire atunci când vă conectați la server. Setați acest parametru la 16 și creșteți după cum este necesar. Verificați indicatorul „Threads_created”, în mod ideal ar trebui să fie egal cu zero:

Mysql> arată starea ca „threads_created”; +-----–+--–+ | Nume_variabilă | Valoare | +-----–+--–+ | Fire_create | 423312 | +-----–+--–+

query_cache_size

Valoarea acestui parametru determină câtă memorie ar trebui utilizată pentru cache-ul de interogări. Nu vă lăsați duși de a stabili valori uriașe. Cache-ul de interogări nu ar trebui să fie mare, deoarece... mysql va consuma resurse pentru gestionarea datelor din cache. Începeți cu 32M...128M și creșteți după cum este necesar.

Începând cu versiunea 3.22, MySQL poate citi opțiunile implicite de pornire pentru server și clienți din fișierele de opțiuni.

Pe Unix, parametrii MySQL impliciti sunt citiți din următoarele fișiere:

DATADIR este directorul de date MySQL (de obicei /usr/local/mysql/data pentru o instalare binară sau /usr/local/var pentru o instalare sursă). Rețineți că acesta este directorul care a fost specificat în timpul instalării, nu cel specificat cu --datadir la pornirea mysqld! (--datadir nu are niciun efect asupra vizualizării de către server a fișierelor cu parametri, deoarece acestea sunt vizualizate înainte ca argumentele liniei de comandă să fie procesate).

Pe Windows, parametrii MySQL impliciti sunt citiți din următoarele fișiere:

Vă rugăm să rețineți că pe Windows toate căile trebuie specificate cu / în loc de \. Dacă trebuie să utilizați \, trebuie să îl specificați de două ori deoarece \ este un caracter de escape în MySQL.

MySQL încearcă să citească fișierele de parametri în ordinea enumerată mai sus. Dacă există mai multe astfel de fișiere, atunci parametrul specificat în fișierul care vine mai târziu are prioritate față de același parametru specificat în fișierul aflat mai devreme. Opțiunile specificate pe linia de comandă au prioritate față de opțiunile specificate în oricare dintre fișierele de opțiuni. Unii parametri pot fi setati folosind variabile de mediu. Opțiunile specificate pe linia de comandă sau în fișierele de opțiuni au prioritate față de variabilele de mediu (vezi Anexa F, variabile de mediu).

Iată o listă de programe care acceptă fișiere cu parametri: mysql, mysqladmin, mysqld, mysqld_safe, mysql.server, mysqldump, mysqlimport, mysqlshow, mysqlcheck, myisamchk și myisampack.

Orice parametru care poate fi specificat pe linia de comandă atunci când rulează un program MySQL poate fi specificat și în fișierul de parametri (fără bară oblică dublă). Pentru a obține o listă de opțiuni disponibile, rulați programul cu opțiunea --help.

Fișierele cu parametri pot conține linii precum următoarele:

    Liniile de comentariu încep cu un caracter „#” sau „;”. Liniile goale sunt ignorate.

    grup este numele programului sau grupului pentru care doriți să setați parametri. Orice parametri sau șiruri care specifică valori variabile care sunt specificate după o linie de grup vor fi alocați grupului numit până când fișierul de parametri se termină sau este specificată o altă linie de grup.

    Echivalent cu --option pe linia de comandă.

    Echivalent cu --option=valoare pe linia de comandă.

    set-variable = variabilă=valoare

    Echivalent cu --set-variable variabilă=valoare pe linia de comandă. Această sintaxă trebuie utilizată pentru a seta variabile mysqld. Rețineți că --set-variable nu este folosit din MySQL 4.0. Folosiți doar --variable=value .

Grupul de clienți oferă posibilitatea de a seta parametri care se aplică tuturor clienților MySQL (cu excepția mysqld însuși). Acest grup este excelent pentru a specifica o parolă de utilizat atunci când vă conectați la server (dar asigurați-vă că numai dvs. aveți permisiunea de a citi și scrie acest fișier).

Rețineți că pentru parametri și valori, orice spații introduse înainte sau după acestea sunt eliminate automat. Următoarele secvențe de escape pot fi utilizate în șiruri de valori: „\b”, „\t”, „\n”, „\r”, „\\” și „\s” (“\s” este un spațiu).

Exemplu de fișier de opțiuni globale tipic:

Port=3306 socket=/tmp/mysql.sock port=3306 socket=/tmp/mysql.sock set-variable = key_buffer_size=16M set-variable = max_allowed_packet=1M rapid

Exemplu de fișier tipic de opțiuni de utilizator:

# Parola specificată va fi trimisă tuturor clienților MySQL standard password=my_password no-auto-rehash set-variable = connect_timeout=2 interactive-timeout

Dacă aveți o distribuție sursă, atunci exemple de fișiere de configurare numite my-xxxx.cnf pot fi găsite în directorul de fișiere de suport. Pentru o distribuție binară, uitați-vă la directorul DIR/support-files, unde DIR este numele directorului de instalare MySQL (de obicei /usr/local/mysql). În prezent există exemple de fișiere de configurare pentru sisteme mici, medii, mari și foarte mari. Pentru a experimenta cu fișierul, puteți copia my-xxxx.cnf în directorul dvs. de acasă (redenumiți copia în .my.cnf).

Toți clienții MySQL care acceptă fișiere de opțiuni acceptă următoarele opțiuni:

Vă rugăm să rețineți că parametrii de mai sus trebuie să apară pe primul loc pe linia de comandă! Cu toate acestea, opțiunea --print-defaults poate fi utilizată imediat după comenzile --defaults-xxx-file.

Notă pentru dezvoltatori: fișierul de opțiuni este procesat după cum urmează: toate opțiunile de potrivire (adică opțiunile din grupurile de potrivire) sunt procesate înaintea oricăror argumente din linia de comandă. Acest algoritm este potrivit pentru programele care, dacă același parametru este specificat de mai multe ori, utilizează ultima instanță a parametrului. Dacă lucrați cu un program mai vechi care citește mai mulți parametri în acest mod, dar nu citește fișierele cu parametri, trebuie doar să adăugați două linii pentru a-i oferi această capacitate. Pentru a vedea cum se face acest lucru, trebuie doar să priviți codul sursă al oricărui client MySQL standard.

Nu știu de ce, dar setările MySQL implicit sunt concepute pentru desktop-uri din anii 90. De exemplu, 8 Mb de memorie pentru indecșii InnoDB. Amintiți-vă cum spunea Bill Gates că „640 KB de memorie ar trebui să fie suficient pentru toată lumea”. Setări MySQL implicite din această serie.

În primul rând, extrasul meu din configurație (4G RAM, AMD Athlon 64 X2 Dual 5600+)

NUMAI # UTF! DOAR HARDCORE! collation_server=utf8_general_ci character_set_server=utf8 default-character-set = utf8 # lasă ca implicit să fie InnoDB default-storage-engine = InnoDB key_buffer_size = 512M innodb_buffer_pool_size = 512M innodb_buffer_pool_size = 512M innodb_buffer_pool_size = 512M innodb_pool_additionalize innodb_flush_log_at_trx_commit = 2 innodb_thread_concurrency = 8 join_buffer_size = 8M sort_buffer_size = 8M read_rnd_buffer_size = 8M tmp_table_size = 64M max_heap_table_size = 32M table_cache = 256 log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 1 query_cache = query_type cache_2 = query_type cache_2 = chery_2

Cum să vezi dacă ceva este în neregulă cu baza de date
Cea mai rapidă opțiune este să accesați phpMyAdmin în fila „Starea actuală MySQL”.
Acolo veți vedea sfaturi despre setările pe care trebuie să le modificați.

Setările în sine pot fi vizualizate în același phpMyAdmin în fila „Variabile de sistem”.

MySQL are mai multe setări cu care puteți overclocka baza de date la prima spațială. În primul rând, setările pentru stocarea indecșilor în memorie. Nu numai că indicii accelerează semnificativ recuperările, dar dacă sunt stocați în memorie și nu pe disc (unde sunt de obicei localizați), profitul va fi semnificativ.

key_buffer_size = 512M
Astfel, alocam 512 Mb pentru indecșii tabelelor MyISAM. Cert este că am jumătate din bazele mele de date în MyISAM (așa s-a întâmplat istoric). 99,9% dintre aceste baze de date sunt folosite pentru citire, așa că nu are rost să treceți la InnoDB.

innodb_buffer_pool_size = 512M
Alocam aceeași cantitate de memorie tabelelor InnoDB.
Aici trebuie să știi când să te oprești. Dacă aveți o bază de date cu o dimensiune de 100 Mb, atunci nu are rost să alocați 1 GB de memorie - oricum nu va fi folosită.
În al doilea rând, trebuie să vă uitați nu la dimensiunea tabelului, ci la dimensiunea indicilor. Exemplu din viața reală: un tabel de 300.000 de comentarii cântărește 300 MB, iar indexurile sale ocupă de 15 ori mai puțin, ceea ce este destul de logic, deoarece indecșii sunt de obicei plasați pe coloane numerice și temporare, și nu pe text. Puteți vizualiza din nou acest lucru în phpMyAdmin

innodb_additional_mem_pool_size = 16M
Cantitatea de memorie alocată de InnoDB pentru a stoca diferite structuri interne.

innodb_flush_method = O_DIRECT
Aici dezactivăm tamponarea tabelelor pentru sistemul de fișiere și îi spunem MySQL să acceseze fișierele direct.

innodb_flush_log_at_trx_commit = 2
La fiecare tranzacție, MySQL scrie un jurnal și îl șterge pe disc (valoarea 1). Valoarea 2 – resetare în memorie. Nu este esențial pentru mine să pierd tranzacții în ultimele 2 secunde dacă serverul se blochează.

join_buffer_size = 8M
Memorie pentru interogări cu îmbinări, atunci când îmbinarea are loc fără utilizarea indecșilor.

sort_buffer_size = 8M
read_rnd_buffer_size = 8M
Util pentru interogări cu sortare ORDER BY și grupare GROUP BY. Dacă valoarea este mică, sortarea are loc într-un tabel temporar de pe disc.

tmp_table_size = 64M
max_heap_table_size = 32M
Setări pentru stocarea tabelelor temporare în memorie. Tabelele temporare sunt adesea formate în timpul îmbinărilor mari.

table_cache = 256
Numărul maxim de mese deschise simultan.

log_slow_queries = /var/log/mysql/mysql-slow.log
timp_interogare_lung = 1