Pīters Zaicevs ir uzņēmuma līdzdibinātājs un izpilddirektorsPerkona.
Viens no veidiem, kā mēs novērtējam lietojumprogrammas, ir veiktspēja. Viena no lietojumprogrammu veiktspējas metrikām ir lietotāja pieredze, kas parasti nozīmē "vai lietotājam bija jāgaida ilgāk par saprātīgu laiku, lai iegūtu vēlamo".
Šis rādītājs dažādos scenārijos var nozīmēt dažādas lietas. Mobilās iepirkšanās lietotnes atbildes laiks nedrīkst pārsniegt pāris sekundes. Darbinieka HR lapā atbildes var aizņemt dažas sekundes ilgāk.
Mums ir daudz pētījumu par to, kā veiktspēja ietekmē lietotāju uzvedību:
- 79 procenti klientu retāk atgriežas lēnā vietnē
- 47 procenti patērētāju sagaida, ka tīmekļa lapa tiks ielādēta 2 sekundēs vai mazāk
- 40 procenti lietotāju pamet vietni, ja tās ielāde prasa vairāk nekā trīs sekundes
- Lappuses ielādes laika aizkavēšanās ar vienu sekundi var izraisīt reklāmguvumu zaudējumus par 7 procentiem un par 11 procentiem mazāk lapu skatījumu
Neatkarīgi no standarta, ir svarīgi saglabāt labu lietojumprogrammu veiktspēju. Pretējā gadījumā lietotāji sūdzēsies (vai vēl sliktāk, pārejiet uz citu lietojumprogrammu). Viens no faktoriem, kas ietekmē lietojumprogrammas veiktspēju, ir datu bāzes veiktspēja. Mijiedarbība starp lietojumprogrammām, vietnēm un datu bāzēm ir kritiska, nosakot lietojumprogrammu veiktspējas līmeni.
Šīs mijiedarbības centrālais komponents ir tas, kā lietojumprogrammas vaicā datu bāzē un kā datu bāze reaģē uz pieprasījumiem. Jebkurā mērā MySQL ir viena no populārākajām datu bāzu pārvaldības sistēmām. Vairāk uzņēmumu savā ražošanas vidē pāriet uz MySQL (un citām atvērtā pirmkoda datu bāzēm) kā datu bāzes risinājumu.
Ir daudzas MySQL konfigurēšanas metodes, kas var palīdzēt nodrošināt, ka jūsu datu bāze ātri un ar minimālu lietojumprogrammas veiktspējas pasliktināšanos atbild uz jautājumiem.
Šie ir daži svarīgi padomi, kas palīdzēs optimizēt MySQL datu bāzes veiktspēju.
MySQL optimizācijas atslēga Nr. 1: uzziniet, kā to izmantot PASKAIDROT
Divi vissvarīgākie lēmumi, ko jūs veicat ar jebkuru datu bāzi, ir dizains, kā attiecības starp lietojumprogrammu entītijām tiek piesaistītas tabulām (datu bāzes shēma), un to, kā lietojumprogrammas iegūst vajadzīgos datus vajadzīgajā formātā (vaicājumi).
Sarežģītās lietojumprogrammās var būt sarežģītas shēmas un vaicājumi. Ja vēlaties iegūt jūsu lietojumprogrammām nepieciešamo veiktspēju un mērogu, jūs nevarat paļauties tikai uz intuīciju, lai saprastu, kā vaicājumi tiks izpildīti.
Tā vietā, lai uzminētu un cerētu, jums vajadzētu uzzināt, kā lietot PASKAIDROT komandu. Šī komanda parāda, kā tiks izpildīts vaicājums, un sniedz ieskatu gan par to, kādu veiktspēju jūs varat sagaidīt, gan to, kā vaicājums tiks mērogots, mainoties datu lielumam.
Ir vairāki rīki, piemēram, MySQL Workbench, kas var vizualizēt PASKAIDROT jums, taču jums joprojām ir jāsaprot pamati, lai to saprastu.
Ir divi dažādi formāti, kuros PASKAIDROT komanda nodrošina izvadi: vecmodīgs tabulas formāts un modernāks, strukturēts JSON dokuments, kas sniedz ievērojami sīkāku informāciju (parādīts zemāk):
mysql> izskaidrot format = json atlasiet avg (k) no sbtest1, kur id ir no 1000 līdz 2000 \ G**************************** 1. rinda ******************** *******
PASKAIDROT: {
“Query_block”: {
“Select_id”: 1,
“Izmaksu_informācija”: {
“Query_cost”: “762.40”
"tabula": {
“Table_name”: “sbtest1”,
“Access_type”: “diapazons”,
“Possible_keys”: [
"PRIMĀRS"
],
“Atslēga”: “PIRMS”,
“Used_key_parts”: [
“Id”
],
“Key_length”: “4”,
“Rows_examined_per_scan”: 1874. gads,
“Rows_produced_per_join”: 1874. gads,
“Filtrēts”: “100,00”,
“Izmaksu_informācija”: {
“Read_cost”: “387.60”,
“Eval_cost”: “374,80”,
“Prefix_cost”: “762.40”,
“Data_read_per_join”: “351 KB”
},
“Used_columns”: [
“Id”,
“K”
],
“Pievienots_nosacījums”: “(“ sbtest ”.“ Sbtest1 ”.“ Id ”starp 1000 un 2000)”
}
}
}
Viens no komponentiem, kas jums jāaplūko, ir “vaicājuma izmaksas”. Vaicājuma izmaksas attiecas uz to, cik dārgs MySQL uzskata šo konkrēto vaicājumu par vaicājuma izpildes kopējām izmaksām, un tas ir balstīts uz daudziem dažādiem faktoriem.
Vienkāršu vaicājumu vaicājumu izmaksas parasti ir mazākas par 1000. Vaicājumi, kuru cena ir no 1000 līdz 100 000, tiek uzskatīti par vidēju izmaksu vaicājumiem un parasti ir ātri, ja sekundē veicat tikai simtiem šādu vaicājumu (nevis desmitiem tūkstošu).
Vaicājumi, kuru izmaksas pārsniedz 100 000, ir dārgi vaicājumi. Bieži vien šie vaicājumi joprojām darbojas ātri, kad sistēmā esat viens lietotājs, taču jums rūpīgi jāpārdomā, cik bieži jūs šādus vaicājumus izmantojat savās interaktīvajās lietojumprogrammās (it īpaši, pieaugot lietotāju skaitam).
Protams, tie ir bumbas laukuma veiktspējas skaitļi, taču tie parāda vispārējo principu. Jūsu sistēma var labāk vai sliktāk apstrādāt vaicājumu darba slodzes atkarībā no tās arhitektūras un konfigurācijas.
Galvenais starp faktoriem, kas nosaka vaicājuma izmaksas, ir tas, vai vaicājums pareizi izmanto indeksus. The PASKAIDROT komanda var pateikt, vai vaicājumā netiek izmantoti indeksi (parasti tāpēc, ka indeksi tiek izveidoti datu bāzē vai kā tiek veidots pats vaicājums). Tāpēc ir tik svarīgi iemācīties lietot PASKAIDROT.
MySQL optimizācijas atslēga Nr. 2: izveidojiet pareizos indeksus
Indekss uzlabo vaicājumu veiktspēju, samazinot datu daudzumu datu bāzē, kas vaicājumiem jāpārbauda. MySQL indeksi tiek izmantoti, lai paātrinātu piekļuvi datu bāzei un palīdzētu ieviest datu bāzes ierobežojumus (piemēram, UNIKĀLA un SVEŠA ATSLĒGA).
Datu bāzes rādītāji ir līdzīgi grāmatu rādītājiem. Tie tiek turēti savā atrašanās vietā, un tie satur informāciju, kas jau atrodas galvenajā datu bāzē. Tās ir atsauces metode vai karte, kur atrodas dati. Indeksi nemaina nevienu no datu bāzes datiem. Viņi vienkārši norāda uz datu atrašanās vietu.
Nav indeksu, kas vienmēr būtu piemēroti jebkurai slodzei. Indeksi vienmēr jāaplūko kontekstā ar vaicājumiem, kurus sistēma darbojas.
Labi indeksētas datu bāzes darbojas ne tikai ātrāk, bet pat viens trūkstošs indekss var palēnināt datu bāzes pārmeklēšanu. Izmantot PASKAIDROT (kā ieteikts iepriekš), lai atrastu trūkstošos indeksus un tos pievienotu. Bet esiet uzmanīgs: nepievienojiet nevajadzīgus indeksus! Nevajadzīgie indeksi palēnina datu bāzu darbību (skatiet manu prezentāciju par MySQL labāko indeksēšanas praksi).
MySQL optimizācijas atslēga Nr. 3: nav noklusējuma!
Tāpat kā jebkurai programmatūrai, arī MySQL ir daudz konfigurējamu iestatījumu, kurus var izmantot, lai modificētu uzvedību (un galu galā arī veiktspēju). Tāpat kā jebkuru programmatūru, administratori ignorē daudzus no šiem konfigurējamajiem iestatījumiem un galu galā tos izmanto noklusējuma režīmā.
Lai iegūtu vislabāko MySQL veiktspēju, ir svarīgi saprast konfigurējamos MySQL iestatījumus un - vēl svarīgāk - iestatīt tos, lai tie vislabāk darbotos jūsu datu bāzes vidē.
Pēc noklusējuma MySQL ir pielāgots maza mēroga izstrādes instalācijai, nevis ražošanas apjomam. Parasti jūs vēlaties konfigurēt MySQL, lai izmantotu visus pieejamos atmiņas resursus, kā arī atļautu lietojumprogrammai nepieciešamo savienojumu skaitu.
Šeit ir trīs MySQL veiktspējas regulēšanas iestatījumi, kas jums vienmēr rūpīgi jāpārbauda:
innodb_buffer_pool_size: Bufera kopa ir vieta, kur dati un indeksi tiek saglabāti kešatmiņā. Tas ir galvenais iemesls, kāpēc kā datu bāzes serveri tiek izmantota sistēma ar lielu RAM apjomu. Ja izmantojat tikai InnoDB krātuves motoru, aptuveni 80 procentus no savas atmiņas parasti piešķirat bufera kopai. Ja jūs izpildāt ļoti sarežģītus vaicājumus vai jums ir ļoti liels vienlaicīgu datu bāzes savienojumu skaits vai arī jums ir ļoti daudz tabulu, jums, iespējams, vajadzēs šo vērtību samazināt par pakāpienu, lai piešķirtu vairāk atmiņas citiem mērķiem.
Iestatot InnoDB bufera kopas lielumu, jums jāpārliecinās, vai tas nav iestatīts pārāk liels, vai arī tas izraisīs mijmaiņu. Tas absolūti nogalina jūsu datu bāzes veiktspēju. Vienkāršs veids, kā pārbaudīt, ir apskatīt darbības maiņu grafikā Sistēmas pārskats Percona uzraudzības un pārvaldības sistēmā:
PerkonaKā redzams šajā diagrammā, dažu maiņu var veikt tik bieži. Tomēr, ja redzat ilgstošu 1 MB sekundes vai ilgāku maiņas darbību, jums būs jāsamazina bufera kopas lielums (vai cits atmiņas lietojums).
Ja jūs nesaņemat vērtību innodb_buffer_pool_size pareizi pirmajā reizē, neuztraucieties. Sākot ar MySQL 5.7, dinamiski var mainīt InnoDB bufera kopas lielumu, nepārstartējot datu bāzes serveri.
innodb_log_file_size: Tas ir viena InnoDB žurnāla faila lielums. Pēc noklusējuma InnoDB izmanto divas vērtības, lai jūs varētu dubultot šo skaitli, lai iegūtu apļveida pārtaisīšanas žurnāla vietas lielumu, ko InnoDB izmanto, lai pārliecinātos, ka jūsu darījumi ir noturīgi. Tas arī optimizē izmaiņu piemērošanu datu bāzē. Iestatīšana innodb_log_file_size ir kompromisu jautājums. Jo lielāku atvēlēto vietu jūs piešķirat, jo labāku sniegumu jūs sasniegsiet rakstīšanas intensīvai slodzei, bet jo ilgāks laiks avārijas atkopšanai, ja jūsu sistēma cieš no strāvas zuduma vai citām problēmām.
Kā uzzināt, vai jūsu MySQL veiktspēju ierobežo pašreizējais InnoDB žurnāla faila lielums? To var pateikt, apskatot, cik daudz no izmantojamās pārtaisīšanas žurnāla vietas faktiski tiek izmantots. Vieglākais veids ir aplūkot Perkonas uzraudzības un pārvaldības InnoDB Metrics informācijas paneli. Zemāk redzamajā diagrammā InnoDB žurnāla faila lielums nav pietiekami liels, jo izmantotā telpa tiek ļoti tuvu tam, cik daudz izmantojamās pārtaisīšanas žurnāla vietas ir pieejamas (norāda sarkanā līnija). Jūsu žurnāla faila lielumam jābūt vismaz par 20 procentiem lielākam par izmantoto vietu, lai jūsu sistēma darbotos optimāli.
Perkonamax_connections: Liela mēroga lietojumprogrammām bieži nepieciešams daudz vairāk nekā noklusējuma savienojumu skaits. Atšķirībā no citiem mainīgajiem, ja jūs to nenoregulējat pareizi, jums nebūs problēmu ar veiktspēju (per se). Tā vietā, ja savienojumu skaits nav pietiekams jūsu lietojumprogrammu vajadzībām, jūsu lietojumprogramma vienkārši nevarēs izveidot savienojumu ar datu bāzi (kas lietotājiem šķiet dīkstāves laiks). Lai šo mainīgo iegūtu pareizi, ir svarīgi.
Var būt grūti uzzināt, cik daudz savienojumu jums nepieciešams sarežģītām lietojumprogrammām ar daudzām sastāvdaļām, kas darbojas vairākos serveros. Par laimi, MySQL ļauj ļoti viegli redzēt, cik daudz savienojumu tiek izmantoti maksimālajā darbībā. Parasti vēlaties pārliecināties, vai starp lietojumprogrammas izmantoto maksimālo savienojumu skaitu un maksimālo pieejamo savienojumu skaitu ir vismaz 30 procentu starpība. Vienkāršs veids, kā apskatīt šos skaitļus, ir izmantot MySQL savienojumu diagrammu MySQL pārskata informācijas panelī Percona pārraudzībā un pārvaldībā. Zemāk redzamajā diagrammā ir parādīta veselīga sistēma, kurā ir pieejams liels skaits papildu savienojumu.
PerkonaViena lieta, kas jāpatur prātā, ir tāda, ka, ja jūsu datu bāze darbojas lēni, lietojumprogrammas bieži rada pārāk daudz savienojumu. Šādos gadījumos jums vajadzētu strādāt ar datu bāzes veiktspējas problēmu, nevis vienkārši atļaut vairāk savienojumu. Vairāk savienojumu var pasliktināt pamatā esošo veiktspējas problēmu.
(Piezīme: kad iestatāt max_connections mainīgais, kas ievērojami pārsniedz noklusējuma vērtību, jums bieži jāapsver citu parametru palielināšana, piemēram, tabulas kešatmiņas lielums un MySQL atļauto atvērto failu skaits. Tomēr tas pārsniedz šī raksta darbības jomu.)
MySQL optimizācijas atslēga Nr. 4: saglabājiet datu bāzi atmiņā
Pēdējos gados mēs esam redzējuši pāreju uz cietvielu diskiem (SSD). Lai gan SSD diski ir daudz ātrāki nekā cieto disku vērpšana, tie joprojām neatbilst tam, lai dati būtu pieejami RAM. Šī atšķirība rodas ne tikai no pašas atmiņas veiktspējas, bet arī no papildu darba, kas datu bāzei jāveic, kad tā izgūst datus no diska vai SSD krātuves.
Izmantojot nesenos aparatūras uzlabojumus, arvien vairāk ir iespējams iegūt datu bāzi atmiņā - neatkarīgi no tā, vai jūs darbojaties mākonī vai pārvaldāt pats savu aparatūru.
Vēl labāka ziņa ir tā, ka, lai iegūtu lielāko daļu atmiņas veiktspējas priekšrocību, jums nav jāiekļauj visa datu bāze atmiņā. Jums vienkārši jāiekļauj atmiņā darba datu kopa - dati, kuriem piekļūstat visbiežāk.
Iespējams, esat redzējis dažus rakstus, kas sniedz dažus konkrētus skaitļus par to, kura datu bāzes daļa jums jāglabā atmiņā, sākot no 10 procentiem līdz 33 procentiem. Faktiski nav numura “viens izmērs der visiem”. Datu apjoms, kas jāiekļauj atmiņā, lai iegūtu vislabākās veiktspējas priekšrocības, ir saistīts ar darba slodzi. Tā vietā, lai meklētu konkrētu “burvju” numuru, jums jāpārbauda, cik daudz I / O datu bāze darbojas līdzsvara stāvoklī (parasti dažas stundas pēc tās sākšanas). Paskaties uz lasījumiem, jo lasījumus var pilnībā novērst, ja datu bāze ir atmiņā. Rakstiem vienmēr būs jānotiek neatkarīgi no pieejamās atmiņas apjoma.
Zemāk jūs varat redzēt I / O, kas notiek InnoDB I / O grafikā InnoDB Metrics informācijas paneļa Percona uzraudzības un pārvaldības panelī.
PerkonaIepriekš redzamajā diagrammā jūs redzat pat 2000 I / O operāciju sekundē, kas parāda, ka (vismaz dažām darba slodzes daļām) datu bāzes darba kopa neietilpst atmiņā.
MySQL optimizācijas atslēga # 5: izmantojiet SSD krātuvi
Ja jūsu datu bāze neder atmiņā (un pat ja tā ir), jums joprojām ir nepieciešama ātra krātuve, lai apstrādātu rakstīšanu un izvairītos no veiktspējas problēmām, kad datu bāze sasilst (tūlīt pēc restartēšanas). Mūsdienās ātra glabāšana nozīmē SSD.
