Programmēšana

10 būtiski padomi par MySQL veiktspēju

Tāpat kā ar visām relāciju datu bāzēm, arī MySQL var izrādīties sarežģīts zvērs, kas var brīdi pārmeklēt līdz apstāšanās brīdim, atstājot jūsu lietojumprogrammas neziņā un jūsu biznesu.

Patiesība ir tāda, ka visbiežāk sastopamās kļūdas ir pamatā MySQL veiktspējas problēmām. Lai nodrošinātu, ka MySQL serveris dungo ar vislielāko ātrumu, nodrošinot stabilu un konsekventu darbību, ir svarīgi novērst šīs kļūdas, kuras bieži aizēno kāds smalkums jūsu darba slodzē vai konfigurācijas slazdā.

Par laimi, daudziem MySQL veiktspējas jautājumiem ir līdzīgi risinājumi, padarot problēmu novēršanu un MySQL pielāgošanu par pārvaldāmu uzdevumu.

Šeit ir 10 padomi, kā iegūt lielisku MySQL veiktspēju.

MySQL veiktspējas padoms Nr. 1: Profilējiet savu darba slodzi

Labākais veids, kā saprast, kā jūsu serveris pavada laiku, ir servera darba slodzes profilēšana. Profilējot darba slodzi, jūs varat atklāt visdārgākos vaicājumus turpmākai pielāgošanai. Šeit vissvarīgākā metrika ir laiks, jo, izsniedzot vaicājumu serverim, jums viss ir ļoti maz, izņemot to, cik ātri tas tiek pabeigts.

Labākais veids, kā profilēt savu darba slodzi, ir tāds rīks kā MySQL Enterprise Monitor vaicājumu analizators vai pt-query-digest no Percona rīkkopa. Šie rīki uztver vaicājumus, kurus izpilda serveris, un atgriež uzdevumu tabulu, kas sakārtota pēc reaģēšanas laika sarukšanas secības, uzreiz uz augšu uzplaukstot visdārgākajiem un laikietilpīgākajiem uzdevumiem, lai jūs varētu redzēt, kur koncentrēt savus centienus.

Darba slodzes profilēšanas rīki grupē līdzīgus vaicājumus, ļaujot skatīt lēnos vaicājumus, kā arī ātros, bet daudzkārt izpildītos vaicājumus.

MySQL veiktspējas padoms Nr. 2: Izprotiet četrus pamatresursus

Lai darbotos, datu bāzes serverim nepieciešami četri pamatresursi: centrālais procesors, atmiņa, disks un tīkls. Ja kāds no tiem ir vājš, nepastāvīgs vai pārslogots, datu bāzes serveris, visticamāk, darbosies slikti.

Izpratne par pamatresursiem ir svarīga divās konkrētās jomās: aparatūras izvēlē un problēmu novēršanā.

Izvēloties aparatūru MySQL, visapkārt nodrošiniet labas veiktspējas komponentus. Tikpat svarīgi, samērīgi labi līdzsvarojiet tos savā starpā. Bieži vien organizācijas izvēlas serverus ar ātru procesoru un diskiem, bet kuriem trūkst atmiņas. Dažos gadījumos atmiņas pievienošana ir lēts veids, kā palielināt veiktspēju pēc lieluma pakāpēm, īpaši attiecībā uz slodzēm, kas saistītas ar disku. Tas varētu šķist pretrunīgi, taču daudzos gadījumos diski tiek pārmērīgi izmantoti, jo nav pietiekami daudz atmiņas, lai turētu servera darba datu kopu.

Vēl viens labs līdzsvara piemērs attiecas uz procesoriem. Vairumā gadījumu MySQL darbosies labi, izmantojot ātrus procesorus, jo katrs vaicājums darbojas vienā pavedienā un to nevar paralēli savienot ar procesoriem.

Runājot par problēmu novēršanu, pārbaudiet visu četru resursu veiktspēju un izmantošanu, uzmanīgi skatoties, lai noteiktu, vai tie darbojas slikti vai vienkārši tiek aicināti darīt pārāk daudz darba. Šīs zināšanas var palīdzēt ātri atrisināt problēmas.

MySQL veiktspējas padoms Nr. 3: neizmantojiet MySQL kā rindu

Rindas un rindām līdzīgi piekļuves modeļi var ielīst jūsu lietojumprogrammā, jums to nezinot. Piemēram, ja iestatāt vienuma statusu tā, lai konkrēts darbinieka process varētu to pieprasīt, pirms rīkojas ar to, jūs neapzināti izveidojat rindu. E-pastu atzīmēšana kā nesūtīti, nosūtīšana un pēc tam atzīmēšana kā nosūtīts ir izplatīts piemērs.

Rindas rada problēmas divu galveno iemeslu dēļ: tās sērijveido jūsu darba slodzi, novēršot uzdevumu paralēlu veikšanu, un to rezultātā bieži tiek izveidota tabula, kurā ir ietverts procesā esošais darbs, kā arī vēsturiski dati no jau sen apstrādātiem darbiem. Abi pieteikumam pievieno latentumu un ielādē MySQL.

MySQL veiktspējas padoms Nr. 4: vispirms filtrējiet rezultātus pēc lētākā

Lielisks veids, kā optimizēt MySQL, ir vispirms veikt lētu, neprecīzu darbu, pēc tam smagu, precīzu darbu pie mazākā, kā rezultātā iegūto datu kopas.

Piemēram, pieņemsim, ka meklējat kaut ko noteiktā ģeogrāfiskā punkta rādiusā. Pirmais rīks daudzu programmētāju rīkjoslā ir lielā apļa (Haversine) formula attāluma aprēķināšanai gar sfēras virsmu. Šīs tehnikas problēma ir tāda, ka formula prasa daudz trigonometrisko darbību, kas ir ļoti intensīvas CPU. Liela apļa aprēķini mēdz darboties lēnām, un mašīnas CPU izmantošana tiek strauji palielināta.

Pirms lielo apļu formulas piemērošanas samaziniet ierakstus nelielai kopas apakškopai un sagrieziet iegūto kopu precīzam lokam. Kvadrāts, kurā ir aplis (precīzi vai neprecīzi), ir vienkāršs veids, kā to izdarīt. Tādā veidā pasaule ārpus laukuma nekad netiek skarta ar visām šīm dārgajām trigera funkcijām.

MySQL veiktspējas padoms Nr. 5: Pārziniet divus mērogojamības nāves slazdus

Mērogojamība nav tik neskaidra, kā jūs varētu ticēt. Faktiski pastāv precīzas mērogojamības matemātiskas definīcijas, kas izteiktas kā vienādojumi. Šie vienādojumi uzsver, kāpēc sistēmas netiek mērogotas tik labi, kā vajadzētu.

Izmantojiet universālo mērogojamības likumu - definīciju, kas ir ērta, lai izteiktu un kvantificētu sistēmas mērogojamības raksturlielumus. Tas izskaidro mērogošanas problēmas, ņemot vērā divas pamatizmaksas: sērijas un šķērsruna.

Paralēlie procesi, kas jāaptur, lai notiktu kaut kas seriālizēts, pēc savas būtības ir ierobežoti. Tāpat, ja paralēlajiem procesiem visu laiku ir nepieciešams tērzēt, lai koordinētu viņu darbu, tie viens otru ierobežo.

Izvairieties no sērijas un šķērsrunas, un jūsu lietojumprogramma tiks mērogota daudz labāk. Ko tas tulko MySQL iekšpusē? Tas atšķiras, taču daži piemēri būtu izvairīšanās no ekskluzīvām slēdzenēm rindās. Šī iemesla dēļ rindas, kas minētas iepriekš 3. punktā, mēdz slikti mērogot.

MySQL veiktspējas padoms Nr. 6: nekoncentrējieties pārāk daudz uz konfigurāciju

DBA parasti tērē ļoti daudz laika konfigurāciju pielāgošanai. Rezultāts parasti nav liels uzlabojums un dažkārt pat var būt ļoti kaitīgs. Esmu redzējis daudz “optimizētu” serveru, kas pastāvīgi avarēja, atmiņā pietrūka un slikti darbojās, kad darba slodze kļuva nedaudz intensīvāka.

Noklusējumi, kas tiek piegādāti kopā ar MySQL, ir viena izmēra derīgi un ļoti novecojuši, taču jums viss nav jākonfigurē. Labāk ir iegūt pareizos pamatus un mainīt citus iestatījumus tikai nepieciešamības gadījumā. Vairumā gadījumu jūs varat iegūt 95 procentus no servera maksimālās veiktspējas, pareizi iestatot apmēram 10 opcijas. Dažas situācijas, kad tas neattiecas, būs tikai jūsu apstākļiem raksturīgas lietas.

Lielākajā daļā gadījumu servera "pielāgošanas" rīki nav ieteicami, jo tie parasti sniedz vadlīnijas, kurām nav jēgas konkrētos gadījumos. Dažos tajos ir iekodēti pat bīstami, neprecīzi padomi - piemēram, kešatmiņas trāpījumu attiecība un atmiņas patēriņa formulas. Tie nekad nebija pareizi, un laika gaitā tie ir kļuvuši vēl mazāk pareizi.

MySQL veiktspējas padoms Nr. 7: Uzmanieties no lapošanas vaicājumiem

Paginējošās lietojumprogrammas mēdz nogādāt serveri uz ceļiem. Rādot rezultātu lapu ar saiti, lai pārietu uz nākamo lapu, šīs lietojumprogrammas parasti grupē un kārto veidos, kuros nevar izmantot rādītājus, un tajās tiek izmantots LIMIT un kompensēt kas liek serverim veikt daudz darba, radot, pēc tam izmetot rindas.

Optimizāciju bieži var atrast pašā lietotāja saskarnē. Tā vietā, lai rezultātos parādītu precīzu lapu skaitu un saites uz katru lapu atsevišķi, varat vienkārši parādīt saiti uz nākamo lapu. Varat arī liegt cilvēkiem iet uz lapām pārāk tālu no pirmās lapas.

Vaicājuma pusē tā vietā, lai izmantotu LIMIT ar kompensēt, varat atlasīt vēl vienu rindu, nekā nepieciešams, un, kad lietotājs noklikšķina uz saites “Nākamā lapa”, šo pēdējo rindu varat norādīt kā sākumpunktu nākamajam rezultātu kopumam. Piemēram, ja lietotājs skatīja lapu ar 101. līdz 120. rindu, jūs izvēlētos arī 121. rindu; lai renderētu nākamo lapu, vaicājiet serverim rindas, kas lielākas vai vienādas ar 121, 21. ierobežojums.

MySQL veiktspējas padoms Nr. 8: dedzīgi saglabājiet statistiku, nevēlaties brīdināt

Uzraudzība un brīdināšana ir būtiska, bet kas notiek ar tipisko uzraudzības sistēmu? Tas sāk sūtīt viltus pozitīvus rezultātus, un sistēmas administratori izveido e-pasta filtrēšanas kārtulas, lai apturētu troksni. Drīz jūsu uzraudzības sistēma ir pilnīgi bezjēdzīga.

Man patīk domāt par uzraudzību divos veidos: metrikas uztveršana un brīdināšana. Ir ļoti svarīgi uztvert un saglabāt visu iespējamo metriku, jo jūs priecāsieties par to iegūšanu, mēģinot noskaidrot, kas sistēmā mainījās. Kādreiz parādīsies dīvaina problēma, un jums patiks iespēja norādīt uz diagrammu un parādīt servera noslodzes izmaiņas.

Turpretī ir tendence pārāk daudz brīdināt. Cilvēki bieži brīdina par tādām lietām kā bufera trāpījumu attiecība vai sekundē izveidoto pagaidu tabulu skaits. Problēma ir tāda, ka šādai attiecībai nav laba sliekšņa. Pareizais slieksnis atšķiras ne tikai no servera uz serveri, bet arī no stundas uz stundu, mainoties darba slodzei.

Tā rezultātā brīdiniet taupīgi un tikai apstākļos, kas norāda uz noteiktu problēmu, ar kuru var rīkoties. Zems bufera trāpījumu koeficients nav darbināms, un tas neliecina par reālu problēmu, taču serveris, kas nereaģē uz savienojuma mēģinājumu, ir faktiska problēma, kas jāatrisina.

MySQL veiktspējas padoms Nr. 9: uzziniet trīs indeksēšanas noteikumus

Indeksēšana, iespējams, ir visvairāk pārprasta tēma datu bāzēs, jo ir tik daudz veidu, kā sajaukt, kā darbojas indeksi un kā serveris tos izmanto. Lai patiešām saprastu, kas notiek, ir jāpieliek daudz pūļu.

Pareizi izstrādātiem indeksiem datu bāzes serverī ir trīs svarīgi mērķi:

  1. Indeksi ļauj serverim atrast blakus esošo rindu grupas, nevis atsevišķas rindas. Daudzi cilvēki domā, ka indeksa mērķis ir atrast atsevišķas rindas, bet atsevišķu rindu atrašana noved pie nejaušām diska darbībām, kas notiek lēni. Daudz labāk ir atrast rindu grupas, no kurām visas vai lielākā daļa ir interesantas, nekā atrast rindas pa vienai.
  2. Indeksi ļauj serverim izvairīties no šķirošanas, lasot rindas vēlamajā secībā. Šķirošana ir dārga. Rindu lasīšana vēlamajā secībā ir daudz ātrāka.
  3. Indeksi ļauj serverim apmierināt visus vaicājumus tikai no indeksa, izvairoties no nepieciešamības vispār piekļūt tabulai. Tas ir dažādi pazīstams kā aptverošs indekss vai tikai indeksa vaicājums.

Ja jūs varat izveidot savus indeksus un vaicājumus, lai izmantotu šīs trīs iespējas, jūs varat padarīt savus vaicājumus par vairākiem lielumiem ātrāk.

MySQL veiktspējas padoms Nr. 10: Izmantojiet savu vienaudžu zināšanas

Nemēģiniet to izdarīt viens pats. Ja jūs nesaprotat kādu problēmu un darāt to, kas jums šķiet loģiski un saprātīgi, tas ir lieliski. Tas darbosies apmēram 19 reizes no 20. Citreiz jūs nokļūsiet trušu caurumā, kas būs ļoti dārgs un laikietilpīgs tieši tāpēc, ka šķiet, ka mēģinātajam risinājumam ir daudz jēgas.

Izveidojiet ar MySQL saistīto resursu tīklu - un tas pārsniedz rīkjoslu un problēmu novēršanas rokasgrāmatu darbību. Ir daži ārkārtīgi zinoši cilvēki, kas slēpjas adresātu sarakstos, forumos, jautājumu un atbilžu vietnēs utt. Konferences, izstādes un vietējo lietotāju grupu pasākumi sniedz vērtīgas iespējas gūt ieskatu un veidot attiecības ar vienaudžiem, kuri var jums palīdzēt.

Tiem, kas meklē rīkus šo padomu papildināšanai, varat apskatīt MySQL Perkonas konfigurācijas vedni, MySQL Percona vaicājumu padomnieku un Percona uzraudzības spraudņus. (Piezīme. Lai piekļūtu šīm pirmajām divām saitēm, jums būs jāizveido Perkonas konts. Tas ir bez maksas.) Konfigurācijas vednis var palīdzēt ģenerēt pamata servera my.cnf failu jaunam serverim, kas ir pārāks par failu paraugiem, kurus piegādā kopā ar serveris. Vaicājumu konsultants analizēs jūsu SQL, lai palīdzētu atklāt potenciāli sliktus modeļus, piemēram, lapošanas vaicājumus (Nr. 7). Perkonas monitoringa spraudņi ir uzraudzības un grafiku veidošanas spraudņu kopums, kas palīdzēs jums dedzīgi saglabāt statistiku un nelabprāt brīdināt (Nr. 8). Visi šie rīki ir brīvi pieejami.

$config[zx-auto] not found$config[zx-overlay] not found