InnoDB stochează datele într-un spațiu de tabele, care este un fel de sistem de fișiere virtuale care se întinde pe unul sau mai multe fișiere de pe un disc. Spațiul de tabelă din InnoDB este folosit în scopuri diferite, nu doar pentru stocarea tabelelor și a indexurilor. De asemenea, conține un jurnal de anulare (versiuni vechi de șiruri de caractere), un buffer de inserare, un buffer tampon de intrare dublă (descris mai jos) și alte structuri interne.
Configurarea spațiului de tabel Fișierele plasate în spațiul tabelă sunt listate în parametrul de configurare innodb_data_file_path. Toate acestea vor fi în directorul, care este specificat de parametrul innodb_data_home_dir. De exemplu:
innoCb_Cata_home_Cir = / var / lib / mysql / innoCb_Cata_file_path = ibCata1: 1G; ibdata2: 1G; ibdata3: 1G
Rezultatul este un spațiu de masă de 3 GB care conține trei fișiere. Uneori, oamenii se întreabă dacă este posibil să utilizați mai multe fișiere pentru a distribui sarcina la mai multe unități, de exemplu:
Cu toate acestea, fișierele sunt de fapt plasate în directoare diferite, care în acest caz sunt pe discuri diferite, dar InnoDB concatenează fișierele unul după altul. Prin urmare, în acest caz, nu veți obține nici un câștig real. InnoDB va scrie mai întâi la primul fișier, atunci când este plin - în al doilea, etc., adică sarcina nu este distribuită așa cum doriți, pentru a asigura performanțe ridicate. În acest scop, este mai bine să utilizați un controler RAID.
Pentru a face spațiul de tabelă să crească atunci când spațiul se termină, puteți face ca ultimul fișier să poată fi extins automat:
În mod implicit, se creează un fișier cu extensie automată de 10 MB. Dacă decideți să faceți fișierul extensibil automat, este logic să limitați dimensiunea spațiului de masă de sus, deoarece, după ce ați atins o anumită dimensiune, fișierul nu mai este compact (nu se micșorează). De exemplu, în următorul exemplu, dimensiunea fișierului extensibil automat este limitată la 2 GB:
Parametrul innodb_file_per_table vă permite să configurați InnoDB cu un fișier pe tabel (începând cu MySQL 4.1). Datele sunt stocate în directorul bazei de date în fișiere cu nume precum tablename.ibd. Deci, este mai ușor să eliberați spațiu atunci când ștergeți o masă, în plus, acest mod este util pentru distribuirea de tabele pe discuri diferite. Cu toate acestea, dacă stocați date în mai multe fișiere, mai mult spațiu este irosit, deoarece schimbați fragmentarea internă într-un spațiu de tabelă pentru spațiul neutilizat în fișierele IBD. Această problemă se aplică în cea mai mare parte tabelelor mici, deoarece dimensiunea paginii în InnoDB este de 16 KB. Chiar dacă numai 1 KB de date este stocată în tabel, va ocupa încă 16 KB pe disc.
Ar trebui de asemenea remarcat faptul că fișierele InnoDB nu trebuie să fie stocate într-un sistem de fișiere tradițional. Ca multe alte DBMS-uri, InnoDB vă permite să le plasați pe o partiție brută a discului. Cu toate acestea, sistemele de fișiere moderne sunt capabile să funcționeze eficient cu obiecte destul de mari, astfel încât în acest mod nu este prea important. Utilizarea dispozitivelor neformate poate da o creștere a performanței de câteva procente, dar nu credem că o astfel de victorie slabă justifică neplăcerile cauzate de incapacitatea de a manipula date cum ar fi fișierele. Dacă acestea sunt pe un dispozitiv neformatat, atunci puteți uita despre comenzile mv, cp și altele. De asemenea, credem că mijloacele de a face instantanee, cum ar fi cele oferite de managerul de volum logic (LVM) în sistemul GNU / Linux, reprezintă o comoditate extraordinară. Desigur, puteți plasa un dispozitiv neformatat pe un volum logic, dar în același timp ideea în sine nu are sens - o astfel de unitate nu mai este neformată. În general, din cauza câștigurilor minuscule pe care le oferă dispozitivele neformate, nu începeți să vă faceți griji.
Versiuni mai vechi de șiruri de caractere și spațiu de tabel Cu înregistrarea intensivă, spațiul de tabel InnoDB poate deveni foarte mare. În cazul în care tranzacția este lăsată deschisă pentru o lungă perioadă de timp (nici măcar nu face nimic util), și în același timp, a stabilit nivelul de izolare repetabile citit, atunci InnoDB nu se poate elimina versiunile vechi de rânduri, deoarece acestea ar trebui considerate tranzacții neangajate. InnoDB stochează versiuni mai vechi într-un spațiu de tabelă, deci continuă să crească odată cu actualizarea datelor. Uneori, problema nu este cu tranzacții deschise, ci pur și simplu la natura volumului de muncă: curățare a implicat un singur fir, poate pur și simplu nu au timp pentru a elimina versiunile vechi de rânduri.
În orice caz, comanda SHOW INNODB STATUS va ajuta la identificarea cauzei problemei. Consultați prima și a doua linie din secțiunea TRANZACȚII, care indică numărul tranzacției curente și punctul la care a avut loc curățarea. Dacă diferența este mare, atunci s-au acumulat multe tranzacții neprelucrate. De exemplu:
Trx id counter 0 80157601
Purjare făcută pentru trx's: o <0 80154573 undo n:o <0 0
Identificatorul tranzacției este un număr pe 64 de biți format din două numere pe 32 de biți, deci va trebui să suferiți un pic pentru a calcula diferența. În acest caz, totul este simplu ca biți semnificativi sunt egali cu 0, deci avem 80157601 - 80154573 = 3028 tranzacții cu potențial necurățate (innotop de utilitate va face pentru tine toate calculele). Spunem "potențial", deoarece o mare diferență nu înseamnă că există multe linii necurățate. Versiunile mai vechi de siruri de caractere sunt numai pentru tranzacții care modifică date și pot exista mai multe tranzacții, în cadrul căreia dat Nye nu sa schimbat (și vice-versa - o tranzacție poate schimba o mulțime de linii).
Dacă există o mulțime de tranzacții necurățate și din acest motiv spațiul tabelă continuă să crească, puteți forța MySQL să încetinească, astfel încât firul de curățare al InnoDB să poată face față sarcinii. Nu sună prea atractiv, dar nu există altă alternativă. În caz contrar, InnoDB va continua să scrie date și să umple discul până când nu se va depăși spațiul sau dacă limita superioară specificată a dimensiunii spațiului tabelă va fi atinsă.
Pentru a „incetini“ de intrare, setați variabila innodb_max_purge_ valoarea lag altele decât 0. Este egal cu numărul maxim de tranzacții care așteaptă să fie curate; La atingerea acestui prag, InnoDB începe să amâne executarea cererilor de actualizare a datelor. Pentru a selecta valoarea corespunzătoare, trebuie să cunoașteți volumul de lucru specific. De exemplu, în cazul în care o tranzacție tipică schimbă o medie de 1 Kbiti de date și sunteți dispus să pună cu 100 MB rânduri „necurățate“ într-un spațiu tabelă, puteți seta valoarea de 100.000.
Rețineți că prezența unor versiuni necurățate ale rândurilor se reflectă în toate interogările, deoarece ele măresc dimensiunea tabelelor și a indexurilor. Dacă debitul de curățare nu face față sarcinii, performanța poate scădea considerabil. Setarea parametrului innodb_max_ purge_lag reduce de asemenea viteza executării interogării, dar aceasta este cea mai mică dintre cele două rele.
Trimiteți-le prietenilor: