Optimalizácia MySQL dotazov. Optimalizácia MySQL: Indexy, pomalé dotazy, konfigurácia

→ Optimalizácia dotazov MySQL

MySQL má veľkú sadu funkcií pre rôzne druhy ( ZORADIŤ PODĽA), zoskupenia ( GROUP BY), odbory ( ĽAVÉ PRIPOJENIE alebo SPRÁVNE PRIPOJTE SA) a tak ďalej. Všetky sú určite pohodlné, ale v podmienkach jednorazových žiadostí. Napríklad, ak osobne potrebujete niečo vykopať v databáze pomocou hromady tabuliek a odkazov, potom okrem vyššie uvedených funkcií môžete a dokonca musíte použiť podmienené operátory AK. Hlavnou chybou začínajúcich programátorov je túžba aplikovať takéto požiadavky v pracovnom kóde stránky. V tomto prípade je zložitý dopyt určite krásny, ale škodlivý. Ide o to, že žiadne operátory triedenia, zoskupovania, spájania alebo vnorených dopytov nie je možné vykonávať v pamäti RAM a na vytváranie dočasných tabuliek používajú pevný disk. A ťažké, ako viete, je prekážkou servera.

pravidlá optimalizácie dotazov mysql

1. Vyhnite sa vnoreným dopytom

Toto je najzávažnejšia chyba. Rodičovský proces bude vždy čakať na dokončenie podriadeného a v tomto čase udrží pripojenie k databáze, použije disk a načíta iowait. Dva paralelné dotazy do databázy a vykonanie potrebného filtrovania v serverovom interpretere ( Perl, PHP atď.) sa vykoná rádovo rýchlejšie ako vnorený.

príklady perlučo nerobiť:

My $sth = $dbh->prepare("SELECT elementID,elementNAME,groupID FROM tbl WHERE groupID IN(2,3,7)"); $sth->execute(); while (my @row = $sth->fetchrow_array()) (my $groupNAME = $dbh->selectrow_array("SELECT groupNAME FROM groups WHERE groupID = $row"); ### Povedzme, že potrebujeme zhromaždiť názvy skupín # ## a pridajte ich na koniec dátového poľa push @row => $groupNAME; ### Urobte niečo iné... )

alebo v žiadnom prípade takto:

My $sth = $dbh->prepare("SELECT elementID,elementNAME,groupID FROM tbl WHERE groupID IN(SELECT groupID FROM groups WHERE groupNAME = "First" OR groupNAME = "Second" OR groupNAME = "Seventh")");

Ak sú takéto akcie potrebné, vo všetkých prípadoch je lepšie použiť hash, pole alebo akýkoľvek iný spôsob filtrovania.

Príklad v perle, ako zvyčajne:

Moje % skupiny; my $sth = $dbh->prepare("SELECT groupID,groupNAME FROM groups WHERE groupID IN(2,3,7)"); $sth->execute(); while (my @row = $sth->fetchrow_array()) ( $groups($row) = $row; ) ### A teraz urobte hlavné načítanie bez poddotazu my $sth2 = $dbh->prepare("SELECT elementID ,elementNAME,groupID FROM tbl WHERE groupID IN(2,3,7)"); $sth2->execute(); while (my @row = $sth2->fetchrow_array()) ( push @row => $groups($row); ### Urobte niečo iné... )

2. V databáze netriedite, nezoskupujte ani nefiltrujte

Pokiaľ je to možné, nepoužívajte vo svojich dopytoch operátory ORDER BY, GROUP BY, JOIN. Všetky používajú dočasné tabuľky. Ak je triedenie alebo zoskupovanie potrebné len na zobrazenie prvkov, napríklad abecedne, je lepšie vykonať tieto akcie v premenných interpreta.

Príklady v Perle, ako netriediť:

My $sth = $dbh->prepare("SELECT elementID,elementNAME FROM tbl WHERE groupID IN(2,3,7) ORDER BY elementNAME"); $sth->execute(); while (my @row = $sth->fetchrow_array()) ( print qq($row => $row); )

Príklad v perle, ako zvyčajne triedim:

Môj $zoznam = $dbh->selectall_arrayref("SELECT elementID,elementNAME FROM tbl WHERE groupID IN(2,3,7)"); foreach (zoradiť ( $a-> cmp $b-> ) @$list)( print qq($_-> => $_->); )

Oveľa rýchlejšie. Rozdiel je viditeľný najmä vtedy, ak je údajov veľa. V prípade, že chcete triediť podľa perl na viacerých poliach je možné použiť Schwartzovo triedenie. Ak sa vyžaduje náhodné triedenie ORDER BY RAND () - použite náhodné triedenie perlu.

3. Použite indexy

Ak je možné v niektorých prípadoch upustiť od triedenia v databáze, potom je nepravdepodobné, že by to bolo úspešné. Preto pre porovnávané polia je potrebné nastaviť indexy. Sú vyrobené jednoducho.

S takouto žiadosťou:

ALTER TABLE `any_db`.`any_tbl` PRIDAŤ INDEX `text_index`(`text_fld`(255));

Kde 255 je dĺžka kľúča. Pre niektoré typy údajov sa nevyžaduje. Podrobnosti nájdete v dokumentácii MySQL.

Od autora: môj priateľ sa rozhodol optimalizovať svoje auto. Najprv si dal dole jedno koleso, tak odpílil strechu, potom motor... Vo všeobecnosti teraz chodí. To všetko sú dôsledky nesprávneho prístupu! Preto, aby váš DBMS pokračoval v „jazde“, musí byť správne vykonaná optimalizácia MySQL.

Kedy optimalizovať a prečo?

Nestojí za to znova vyliezť do nastavení servera a zmeniť hodnoty parametrov (najmä ak neviete, ako by to mohlo skončiť), nestojí za to. Ak vezmeme do úvahy túto tému zo „zvonice“ zlepšovania výkonnosti webových zdrojov, potom je taká rozsiahla, že jej treba venovať celú vedeckú publikáciu v 7 zväzkoch.

Ale ja očividne nemám takú trpezlivosť pri písaní a vy nemáte ani čitateľskú trpezlivosť. Urobíme to jednoduchšie a pokúsime sa len trochu ponoriť do húštin optimalizácie servera MySQL a jeho komponentov. Pomocou optimálneho nastavenia všetkých parametrov DBMS možno dosiahnuť niekoľko cieľov:

Zvýšte rýchlosť vykonávania dotazu.

Zlepšite celkový výkon servera.

Skráťte čas čakania na načítanie stránok zdrojov.

Znížte spotrebu kapacít hostingového servera.

Znížte množstvo zaberaného miesta na disku.

Celú tému optimalizácie sa pokúsime rozobrať do niekoľkých bodov, aby bolo viac-menej jasné, prečo „hrnec“ vrie.

Prečo nastaviť server

V MySQL by optimalizácia výkonu mala začať zo servera. V prvom rade by ste mali zrýchliť jeho prácu a skrátiť dobu spracovania žiadostí. Univerzálnym prostriedkom na dosiahnutie všetkých týchto cieľov je umožnenie ukladania do vyrovnávacej pamäte. Neviete "čo je to"? Teraz všetko vysvetlím.

Ak je na inštancii vášho servera povolené ukladanie do vyrovnávacej pamäte, systém MySQL si automaticky „zapamätá“ dotaz zadaný používateľom. A pri ďalšom opakovaní sa tento výsledok dotazu (pre výber) nespracuje, ale vezme sa zo systémovej pamäte. Ukazuje sa, že týmto spôsobom server „šetrí“ čas na odoslanie odpovede a v dôsledku toho sa zvyšuje rýchlosť odozvy stránky. To platí aj pre celkovú rýchlosť sťahovania.

V MySQL je optimalizácia dotazov použiteľná pre tie motory a CMS, ktoré pracujú na základe tohto DBMS a PHP. Zároveň si kód napísaný v programovacom jazyku na generovanie dynamickej webovej stránky vyžaduje niektoré jej štrukturálne časti a obsah (príspevky, archívy a iné taxonómie) z databázy.

Vďaka povolenému ukladaniu do vyrovnávacej pamäte v MySQL je vykonávanie dotazov na server DBMS oveľa rýchlejšie. Vďaka tomu sa zvyšuje rýchlosť sťahovania celého zdroja ako celku. A to má pozitívny vplyv ako na používateľskú skúsenosť, tak aj na pozíciu stránky v problematike.

Povoľte a nakonfigurujte ukladanie do vyrovnávacej pamäte

Vráťme sa však od „nudnej“ teórie k zaujímavej praxi. Ďalšia optimalizácia databázy MySQL bude pokračovať kontrolou stavu vyrovnávacej pamäte na vašom databázovom serveri. Na tento účel pomocou špeciálneho dotazu zobrazíme hodnoty všetkých systémových premenných:

Celkom iná vec.

Urobme si malý prehľad získaných hodnôt, ktoré sa nám budú hodiť pri optimalizácii MySQL databáz:

have_query_cache - hodnota označuje "ON" ukladanie dotazov do vyrovnávacej pamäte alebo nie.

query_cache_type - Zobrazuje aktívny typ vyrovnávacej pamäte. Potrebujeme hodnotu "ON". To znamená, že ukladanie do pamäte cache je povolené pre všetky typy výberu (príkaz SELECT). Okrem tých, ktoré používajú voľbu SQL_NO_CACHE (zakazuje ukladanie informácií o tomto dotaze).

Všetky nastavenia máme nastavené správne.

Meriame cache pre indexy a kľúče

Teraz musíte skontrolovať, koľko pamäte RAM je pridelených pre indexy a kľúče. Odporúča sa nastaviť tento dôležitý parameter pre optimalizáciu databázy MySQL na 20-30% veľkosti RAM dostupnej pre server. Napríklad, ak sú pre inštanciu DBMS pridelené 4 "hektáre", potom pokojne dajte 32 "metrov". Všetko však závisí od vlastností konkrétnej databázy a jej štruktúry (typov) tabuliek.

Ak chcete nastaviť hodnotu parametra, musíte upraviť obsah konfiguračného súboru my.ini, ktorý sa v Denveri nachádza na nasledujúcej ceste: F:\Webserver\usr\local\mysql-5.5

Súbor sa otvorí pomocou programu Poznámkový blok. Následne v ňom nájdeme parameter key_buffer_size a nastavíme optimálnu veľkosť pre váš PC systém (v závislosti od veľkosti „hektárov“ RAM). Potom musíte reštartovať databázový server.

DBMS používa niekoľko ďalších podsystémov (nižšia úroveň) a všetky ich hlavné nastavenia sú tiež špecifikované v tomto konfiguračnom súbore. Preto, ak potrebujete optimalizovať MySQL InnoDB, vitajte tu. Tejto téme sa budeme podrobnejšie venovať v niektorom z našich ďalších článkov.

Meranie úrovne indexov

Použitie indexov v tabuľkách výrazne zvyšuje rýchlosť spracovania a generovania DBMS odpovede na zadaný dotaz. MySQL neustále „meria“ úroveň využitia indexov a kľúčov v každej databáze. Ak chcete získať túto hodnotu, použite dotaz:

ZOBRAZIŤ STAV AKO "handler_read%"

ZOBRAZIŤ STAV AKO "handler_read%"

Vo výsledku nás zaujíma hodnota v riadku Handler_read_key. Ak je uvedené číslo malé, znamená to, že indexy sa v tejto databáze takmer nikdy nepoužívajú. A toto je zlé (ako u nás).

• Uverejnil Nikolaj Korotkov
• Dátum: 8. 12. 2012 o 14:04

Načo to všetko je? Čo to ovplyvňuje? Ako preniesť do reality? Na všetky tieto otázky sa pokúsim dať jasnú odpoveď v tomto príspevku!

A teraz trochu pozadia. Vo všeobecnosti som nedávno dostal na svoju e-mailovú adresu list s nasledujúcim obsahom:

Priemerná záťaž vygenerovaná vaším účtom za posledné 3 dni ******* , vymyslené 119% z povolenej úrovne vášho tarifného plánu. Odporúčame vám prejsť na tarify VPS. Upozorňujeme, že v prípade pravidelného prekračovania limitov si vyhradzujeme právo zablokovať váš účet v súlade s bodom Zmluvy...

Obaja na, plachtili - pomyslel som si v tej chvíli! Súhlasíte, nie je veľmi príjemné dostávať takéto listy. A keďže som sa s takýmto problémom stretol prvýkrát, viete si predstaviť, aký som bol zmätený? Moje rozhorčenie nemalo hraníc! Aký nafig VPS? Môžem len povedať, že som sa usadil na jednej tarife, ale tu mi ponúkajú prechod na zdieľaný hosting, ktorý je trikrát drahší. No nie, chlapci, - myslím, - je ešte skoro.

Píšem spätný list svojmu hostiteľovi, v ktorom ho žiadam, aby mi vysvetlil, prečo môj náklad prechádza cez strechu? Môj blog má predsa len niečo vyše dvoch mesiacov. A návštevnosť nie je veľká. Vo všeobecnosti píšem, že som kategoricky proti prechodu na VPS, myslím si, že v tak ranom štádiu vývoja zdrojov nie je vhodné a žiadam vás, aby ste mi poukázali na moje chyby, čo s nimi robiť a ako ich kontrolovať v budúcnosti!

Ako odpoveď dostávam nasledovné:

Vážený účastník, teraz vás neodpojíme, toto je banálne varovanie, ale hovoria, že s tým treba niečo urobiť. Problém prekročenia záťaže nezávisí priamo od návštevnosti, ale vo väčšej miere závisí od nesprávnej optimalizácie vášho zdroja. Na sledovanie zaťaženia sme na ovládacom paneli zobrazili počítadlo, ktoré sa aktualizuje každých 10 minút:

No ďakujem za vysvetlenie, pomyslím si. Idem študovať problém. Po zadaní otázky „ako znížiť zaťaženie hostingu“ na internete som si uvedomil, že nie som jediný, ale v skutočnosti je problém celkom relevantný. A skôr či neskôr sa to mnohých dotkne. Po podrobnejšom preskúmaní problému som si uvedomil, že z tejto situácie mám dva spôsoby:

1. Požiadajte o pomoc profesionálov (nezávislých pracovníkov) a zaplatte im určitú sumu peňazí, ktorá bude vždy načas.
2. Skúste problém vyriešiť sami.

Vybral som si teda druhú možnosť a poviem vám úprimne, zatiaľ som neoľutoval ani gram. Podarilo sa mi znížiť záťaž na hosťovaní dvakrát alebo trikrát. Tu sa presvedčte sami:

Rozdiel je na mieste! Teraz vám ukážem a poviem, čo som pre to urobil:

— optimalizácia databázy mysql, čo výrazne ovplyvnilo zaťaženie hostingu a zrýchlenie wordpressu;
- zbavili sme sa asi 8 nepotrebných pluginov.
- zrýchlil som wordpress úpravou niekoľkých súborov tém môjho blogu.

Keďže materiál je dosť objemný, rozhodol som sa ho rozdeliť na tri časti. V tomto článku sa dozviete, ako znížiť zaťaženie hostingu optimalizáciou databázy. V ďalšom článku vám to prezradím. A posledný článok bude na túto tému. Keď som to všetko urobil so svojím zdrojom, bol som šokovaný, ako sa môj blog začal načítavať! V porovnaní s tým, čo to bolo, začal lietať.

Vo všeobecnosti bude materiál, ktorý získate z týchto troch príspevkov, jednoducho úžasný. Nenechajte si ujsť, !

Optimalizácia databázy

Skôr ako začnete s databázou vykonávať rôzne akcie, určite si urobte zálohu. Aby ste v prípade problémov mohli všetko rýchlo obnoviť. Databáza obsahuje celú históriu vášho zdroja, ukladá všetky záznamy, ktoré sú na vašom blogu! Vo všeobecnosti vám odporúčam, aby bolo pravidlom ukladať databázu každý deň! Zaberie vám to doslova 1 minútu, no vždy budete pokojne spať. Vieš, stať sa môže čokoľvek.

1. Zálohujte databázu

Pre pohodlie pripojenia na server a spracovanie údajov používam . Veľmi skvelá vec, niekedy napíšem samostatný príspevok o tomto klientovi, . Vo všeobecnosti musíte ísť na svoj server a vyhľadať kartu „Databázy“ alebo „Databázy MySQL“, niečo také. Na každom serveri je databáza, server si môže pri prechode vyžiadať heslo. Musíte to mať. Pri kúpe hostingu je poskytnuté heslo.

V dôsledku toho by ste mali byť na tejto stránke, phpMyAdmin:

Do databázy vstúpite kliknutím na jej názov. Otvorí sa pred vami tabuľka databázy (kliknutím zväčšíte):

Kliknite na "Exportovať" a "OK". Uložiť na vašom PC. Všetko, databáza je uložená, teraz ju môžeme začať optimalizovať. Upozorňujeme, že ak má váš hosting pole „Uložiť ako súbor“, nezabudnite začiarknuť políčko vedľa neho! A tiež si zapamätajte, koľko vaša databáza momentálne váži, a potom uvidíte, koľko bude vážiť po optimalizácii.

Pred optimalizáciou mi to vážilo 26 Mb - to je STRAŠNÉ, ale čo teraz? A teraz váži len 2 Mb! Viete si predstaviť, koľko zbytočného odpadu v sebe obsahovala? Viete si predstaviť, akú záťaž to vytvorilo na serveri? Po optimalizácii databázy môj blog začal lietať ako prúdové lietadlo! Vo všeobecnosti, po vykonaní všetkých krokov popísaných nižšie, pocítite významný rozdiel!

2. Zakážte revízie príspevkov a nastavte minimálnu dobu uloženia vymazaných súborov v koši

Čo je to po revízii? Keď napíšete blogový príspevok, wordpress po určitom čase automaticky uloží záložnú kópiu každého príspevku do databázy, vo všeobecnosti sa automaticky uloží. Teraz si predstavte, keď napíšete 50 blogových príspevkov? Koľko kópií príspevkov si ponecháte? Toto je DOBRÉ! Počas písania príspevku už máte za sebou najmenej 10 automatických uložení!

Navyše, ak vymažete súbory, hromadia sa vo vašom koši, čím sa načíta aj databáza. Samozrejme, je dobré, ak súbor okamžite vymažete z koša, no často sa stáva, že naň veľa ľudí zabudne a niektorí sa len upchajú! A toto, ach, ako nie dobré... Databáza rastie, zaťaženie servera je stále väčšie a väčšie, blog sa načítava stále pomalšie a pomalšie... Premýšľali ste niekedy nad tým, aké následky to môže mať?

Tu je hlavná časť dôsledkov, ale nie všetky: úpadok, časté zlyhania, zhoršovanie stavu, znižovanie pozícií vo výsledkoch vyhľadávačov... A potom je autor zúfalý z neopodstatnených očakávaní. Chuť blogovať sa časom vytratí a je to! Zrútiť sa!

Čo o tom všetkom hovorím? Databáza musí byť neustále monitorovaná a udržiavaná v dobrom stave. Pochopte, že databáza je ako srdce blogu. Pri neustálom zaťažovaní srdca zbytočným svinstvom to časom nevydrží a STOP! Myslím, že mi rozumieš? Takže dosť hororových príbehov a prejdite na optimalizáciu databázy.

Otvorte si teda súbor wp-config.php, nachádza sa v koreňovom adresári vášho blogu, t.j. váš hosting/httpdocs alebo public_html (v závislosti od hostingu)/wp-config.php. A pridajte k tomu dva riadky:

1 2	define("WP_POST_REVISIONS" , false) ; definuj ("EMPTY_TRASH_DAYS" , 1 ) ;

Riadok #1 zakazuje revíziu príspevkov, riadok #2 znamená, koľko dní budú odstránené súbory uložené vo vašom koši. Ako vidíte, dal som „1“, samozrejme, môžete zadať „0“, ale ak sa vám zrazu z nedbanlivosti zatrasie ruka a kliknete na odkaz „vymazať“, všetko je KAPETS!

A po 5-8 hodinách sedenia za počítačom verte, že sa to dá! Takže radšej nechávam číslo "1". Samozrejme, že po vymazaní súboru je lepšie kôš ihneď vysypať ručne, ale aj keď na to zabudnete, súbor sa z koša po dni automaticky vymaže! U mňa to vyzerá takto:

3. Odstráňte revízie príspevkov

Ak sme v predchádzajúcom odseku zakázali revíziu príspevkov, potom v tomto odseku musíme vymazať všetky revízie príspevkov, ktoré sa nahromadili počas celej doby blogovania. Ak ste to nikdy neurobili, zachovali ste ich neuveriteľne veľa! Poďme na to. Skopírujte tento riadok sem:

Vráťme sa k databáze MySQL, ako je popísané v prvom odseku. Prejdite na kartu SQL, vložte skopírovaný riadok do poľa a kliknite na tlačidlo "OK":

Databáza sa opýta:

Odpovieme „OK“ a pozrieme sa, koľko zbytočných revízií príspevkov obsahovala vaša databáza a ako dlho trvalo spracovanie žiadosti. A každý čas dáva svoje zaťaženie:

Čistenie som robil pred 3 dňami, takže pre mňa ešte nezískal revízie. Keď som prvýkrát vyčistil databázu, vymazal som už 1800 nepárnych riadkov! Viete si predstaviť, koľko kópií nepotrebných príspevkov v ňom bolo uložených? Pohni sa.

4. Optimalizujte príspevky vo wp-post

Priečinok wp-post obsahuje všetky blogové príspevky. Rovnako ako v predchádzajúcom odseku skopírujte riadok:

OPTIMALIZÁCIA TABUĽKY wp_posts;

A vložte ho do poľa dotazu SQL. Kliknite na "OK", pozrite sa:

Všetky požiadavky boli dokončené!

5. Vyčistite wp-postmeta

Čo presne čistíme? Priečinok wp-postmeta obsahuje:

- čas poslednej úpravy niektorého z príspevkov. Nezáleží na tom, ale zaťaženie servera, ktoré nie je žiadne, ale dáva;
- obsah predchádzajúcej (ľudsky zrozumiteľnej adresy URL). Ak ste niekedy zmenili trvalý odkaz v akomkoľvek príspevku. Keď ho potom zmeníte, neodstráni sa, ale usadí sa v priečinku wp-postmeta a načíta vašu databázu.

Robíme to isté, skopírujeme tento kód:

Prilepte ho do poľa dotazu SQL a kliknite na tlačidlo OK. Pozrime sa na výsledok:

6. Odstráňte spamové komentáre

Robí sa to rovnakým spôsobom, skopírujte kód:

Vložte do poľa SQL dotaz, kliknite na "OK", pozrite sa na výsledok:

Ako vidíte "0". Po vyplnení tejto požiadavky zabudnete na spamové komentáre!

7. Odstráňte pingbacky

Pingbacky sú upozornenia, že niekto odkazuje na váš príspevok alebo stránku. Nepotrebujeme to, extra náklad! Odstrániť!

8. Zakázať pingbacky

Z posledného odseku sme zistili, že pingbacky neprinášajú nášmu zdroju žiaden úžitok, ale iba ho upchávajú. Tak ich jednoducho vypnime. Skopíruj tento kód:

AKTUALIZÁCIA wp_posts p SET str. ping_status="zatvorené"

No ako sa vám páči toto upratovanie? Páčilo sa ti to? Teraz sa pozrite, koľko začala vážiť vaša databáza po jej optimalizácii? Výrazne zmenšená veľkosť? A povedal som ti! Pozrite sa, ako sa váš blog načítava! Musí lietať! To však na dnes nie je všetko. Teraz zvážime posledný bod, ktorý tiež výrazne zlepší optimalizáciu.

9. Nainštalujte doplnok Optimize DB Plugin

Tento plugin som už krátko spomenul. Nuž, poďme sa bližšie pozrieť na to, ako ho používať. Tento plugin, uhádli ste, pomáha optimalizovať databázu! Stiahnite si archív s doplnkom do svojho počítača a aktivujte ho:

To je všetko, vaša databáza je ďalej optimalizovaná pomocou pluginu:

Po optimalizácii deaktivujte doplnok, aby nezaťažoval váš zdroj. A vo všeobecnosti vám odporúčam vykonávať všetky vyššie uvedené činnosti s frekvenciou raz za mesiac, ešte častejšie. A potom sa váš blog načíta rýchlosťou blesku a zaťaženie servera bude minimálne.

A v ďalšej časti príspevku vám ukážem, ako nahradiť niektoré nepotrebné pluginy kódmi. Určite si nič nenechajte ujsť. Toto bude silný príspevok, po ktorom bude váš server ľahký ako pierko!

A tým sa s vami rozlúčim. To je na dnes všetko, prajem vám všetkým úspech a pamätajte, že ide o obrovské zníženie zaťaženia vášho zdroja. Ahojte všetci a čoskoro sa uvidíme.

A na záver časť vtipov:

Tak ako sa vám páči článok? Som si istý, že po prečítaní a odporúčaniach s vaším zdrojom budete spokojní! Teším sa na vaše komentáre!

Páčil sa vám článok? Zdieľajte so svojimi priateľmi!

Každý komentátor dostane knihu ako darček!

Kniha obsahuje podrobný popis najefektívnejších metód propagácie vášho zdroja!

60 komentárov

1. Alexander 8. decembra 2012 15:18

   A viem, prečo vaša pracovná záťaž tak narástla. Len som si tu s tebou zvykol a neustále niečo študujem. A čo ak je tu infa v pohode. Ale vážne, odporúčam, aby všetky vyššie uvedené rady robili v prvom rade všetci blogeri. Urobil som to už dávno, takže spím pokojne. Napriek tomu je doplnok Optimize DB vo všeobecnosti povinným atribútom každého blogu. Vďaka Kolya, ako vždy, všetko je užitočné a relevantné. A teším sa na ďalší príspevok. Tak choď písať

2. 9. december 2012 16:19

   Bojím sa hrabať v databáze, ale po nainštalovaní a vyčistení pluginom WP-Cleanup klesla z takmer 50 na 7Mb. Blog sa naozaj začal načítavať oveľa rýchlejšie.

3. 9. december 2012 20:39

   Presne povedané, nie je to samotná databáza, ktorá sa pri operáciách s databázou nepýta (DBMS vo všeobecnosti, všetky akcie sú rovnaké, nič sa nepýta), ale klient, phpMySql.

   Čo sa týka pingbackov: „Od posledného bodu sme zistili, že pingbacky neprinášajú nášmu zdroju žiadny úžitok, ale iba ho upchávajú.“ Presne povedané, nič sa nezistilo.

   Práve ste povedali bez toho, aby ste sa hádali, že nie sú potrebné, to je všetko. V skutočnosti môžu byť užitočné, stačí použiť tento nástroj na určený účel. Hovorí vám niečo napríklad kľúčové slovo „sémantický web“?

4. 10. december 2012 08:36
5. Jurij 16. decembra 2012 23:49

   Ahoj môj priateľ!

   Tvoj príspevok je naozaj úžasný. Na internete sa píše toľko nezmyslov, že informácie treba hľadať kúsok po kúsku. A tu som šiel a na vás je všetko zrozumiteľné a zrozumiteľné. Práve som začal mať problém so zaťažením servera. Odporúčam tiež nainštalovať plugin WP Super Cache. Len ho treba správne nakonfigurovať. Skvelý plugin! Možno sa v iných tvojich príspevkoch o ňom niečo hovorí, ale ešte som to nečítal. Ponáhľam sa prejsť k druhej časti optimalizácie. Veľa šťastia vám a vášmu blogu

6. 25. december 2012 11:40 hod
7. 28. januára 2013 11:24 hod

   Dobrý deň! Veľmi zaujímavé, ale čo môj blog na Bloggeri? Všetky pluginy pre WP nie sú vhodné pre Blogspot, optimalizačné metódy si musíte hľadať sami na internete.

   S pozdravom Vadim.

8. Anton 2. apríla 2013 20:34

   Ďakujem za naozaj dobrý príspevok. Mimochodom, po vykonaní bodu číslo 3 mám - „4145 riadkov bolo vymazaných. (Požiadavka trvala 7,0269 sekúnd.)“

9. 14. júl 2013 19:04

   Zaujímavé, ale nejako môžete vyčistiť databázu od starých pluginov? Určite tam boli aj nejaké stopy po nich?

10. 14. júl 2013 19:06

    After: a tiež veľmi podobný vášmu textu tu dayafternight.ru/wordpress/baza-dannih-mysql-optimizacia

11. 12. september 2013 12:57 hod

    Ďakujem Nikolay, správna vec.

    Všetko je prístupné a prehľadne napísané.

    Vyšiel už článok o kódoch?

12. 12. september 2013 13:05

    Nikolay sa zabudol opýtať, povedz mi to, prosím. Keď som vykonal optimalizáciu, našiel som novú databázu information_schema v mojom PhpMyadmine

    Odkiaľ mohla prísť?

    Nedávno bol vložený iba metrický kód Yandex.

    Natalya Gegerová

    Ignorujte to... Väčšina moderných serverov to má! Dôvodom je vydanie MySQL verzie 5.0 a vyššej...

    INFORMATION_SCHEMA je virtuálna databáza, ktorá sa vytvára pri štarte servera a obsahuje metadáta všetkých databáz, t.j. informácie o štruktúre databázy. Je k dispozícii iba na čítanie.

13. 27. október 2013 01:06

    och, základ som čistil podľa vašej metódy + od seba perami, výsledok je zrejmý. Predtým mala databáza 20 MB, teraz 5 MB

14. 29. október 2013 23:34

    Ďakujem veľmi pekne za článok. Dnes som dostal od hostiteľa aj zástrčku. V dôsledku akcií sa základ z 25Mb stal 5.2. Existujú 2 otázky, všetky tieto manipulácie by sa mali vykonávať pravidelne? A druhá otázka, nainštaloval som plugin, kliknem na optimalizáciu, v dôsledku toho je oproti každému riadku napísané,

    poznámka: Tabuľka nepodporuje optimalizáciu, namiesto toho robí recreate + analysis

    Nevyzerá všetko dobre?!

    Prosím! Áno, robím všetky tieto manipulácie, asi raz za mesiac. O doplnku však zatiaľ nemôžem nič povedať, zrejme ste urobili niečo zle. Skúste si o tom vyhľadať informácie na internete. Ale sú aj dobré veci. Na mojom blogu ste zanechali 2100. komentár a za to máte nárok na cenu 100 rubľov:

    

    Pošlite číslo svojej peňaženky wmr a ja vám prevediem peniaze.

15. 30. október 2013 13:27

    Ďakujeme, cena bola prijatá. Ako som sa dostal na vašu stránku?! Včera opäť prestala fungovať stránka a na obrazovke bolo napísané "Chyba pri pripájaní k databáze." Napísal som hostiteľovi, potvrdili mi, že je veľká záťaž na MySQL a urobte s tým niečo, ale zatiaľ prešli na vyššiu tarifu. Hneď som začala pátrať čo mám robiť a našla som tvoj článok, ktorý mi zmenšil základ 5x. Plugin, ktorý spočiatku nechcel fungovať, stále fungoval, ale hlavný problém, odstrániť nepotrebné požiadavky, nebol vyriešený. Už mám nainštalovaný doplnok WP Super Cache, ale ukladá do vyrovnávacej pamäte stránky, nie databázové dotazy. A tak som do štvrtej hodiny ráno hľadal plugin, ktorý by mi vedel pomôcť s požiadavkami a našiel som ho. WP File Cache ukladá požiadavky do vyrovnávacej pamäte, počet požiadaviek a MB pamäte sa výrazne zníži. Na stránkach, kde bolo predtým 40 požiadaviek a 35 MB, je teraz 9 a 12 MB. Jediná vec je, že sa zdá, že rýchlosť sťahovania sa trochu zvýšila, ale len mierne, vzhľadom na to, že rýchlosť načítania mojej stránky je v priemere 0,15-0,5 sekundy. Možno budú tieto informácie niekoho zaujímať.

16. 7. december 2013 15:41

    Môžu vyššie uvedené akcie ovplyvniť fungovanie doplnku nrelate-flyout?

Stupeň zaťaženia servera, a teda aj rýchlosť načítania stránky, vo veľkej miere závisí od toho, ako dobre sú optimalizované dotazy do databázy mySQL. Optimalizácia dopytov mySQL pomôže uvoľniť server a skrátiť čas načítania vašej stránky.

Prečo optimalizovať databázové dotazy

Majitelia stránok, ktoré sú spravované samostatne napísanými administračnými systémami, jednoducho musia dobre pochopiť, ktoré databázové dotazy sa vykonávajú rýchlo a jednoducho a ktoré výrazne zvyšujú zaťaženie servera a výrazne spomaľujú rýchlosť načítania stránok.

Neublíži tým webmasterom, ktorí používajú známe administračné systémy a radi pripájajú najrôznejšie pluginy tretích strán, ako aj upravujú témy pre seba, napríklad na najpopulárnejšom free CMS - WordPress, aby sa dostali k srdcu veci.

Niektoré akcie možno vykonať rôznymi spôsobmi, napríklad môžete spočítať počet záznamov nájdených v tabuľke pomocou funkcie mysql_num_rows (ale neodporúča sa to), alebo môžete použiť konštrukciu SELECT COUNT (). Osobne sme vykonali štúdiu, v ktorej sme vytvorili obrovskú dátovú tabuľku obsahujúcu niekoľko stoviek tisíc záznamov a vážiacu viac ako jeden gigabajt a potom sme sa pokúsili spočítať počet riadkov uvedenými spôsobmi.

Výsledok bol viditeľný voľným okom, pretože v prípade použitia mysql_num_rows stránka visela na 5 sekúnd, po ktorých sa zobrazil výsledok. V druhom prípade sme takmer okamžite dostali výsledok v podobe počtu záznamov v tabuľke. Čas načítania skriptu sme ani nemuseli merať mikročasovačom, pretože výsledok bol viac než zrejmý.

To isté platí pre ostatné dizajny. Niektoré databázové operácie je možné vykonávať dvoma, tromi, štyrmi alebo viacerými spôsobmi, pričom každý z nich sa bude presne líšiť rýchlosťou, pričom výsledok bude vo všetkých prípadoch rovnako pravdivý.

Ako optimalizovať databázové dotazy

Aby sme presne pochopili, ako optimalizovať dopyty a ktoré konštrukcie sú rýchlejšie a ktoré pomalšie, opäť urobíme malý experiment a urobíme to hneď teraz.

Pre pomoc sa budeme musieť obrátiť na rozhranie obľúbeného a veľmi pohodlného phpmyadmina. Aby sme mohli začať, musíme si vybrať jednu z dostupných databáz a vytvoriť v nej testovaciu tabuľku. Jeho názov bude v našom prípade skôr banálny - test.

CREATE TABLE `test` (`ID` INT NOT NULL AUTO_INCREMENT , `TITLE` VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL , `ANNOUNCEMENT` TEXT SET CHARACTER NOT utf8 COLLATE` utfci_CHF8_ NULL , PRIMÁRNY KĽÚČ (`ID`)) ENGINE = MYISAM ;

Teraz, keď už máme testovaciu tabuľku, musíme ju vyplniť abstraktnými údajmi. Ako môžete vidieť zo štruktúry tabuľky, ktorú sme práve vytvorili, na vyplnenie potrebujeme nasledujúce údaje:

• hlavička
• Oznámenie
• Celý text

Pre abstraktné texty, zo zvyku, pôjdeme do služby Yandex.Abstracts, vytvorenej práve na takéto účely. Mali sme to šťastie, že sme narazili na tému „Torzný fotón v 21. storočí“ a berme to.

Ako nadpis sme uviedli náhodne vybranú tému, ako oznámenie sme zobrali jeden priemerný odsek textu a ako plné znenie článku budeme mať text s dĺžkou 4000 znakov s medzerami. Na počítanie počtu znakov v texte sme použili vlastnú službu a odporúčame vám do nej počítať, pretože. existuje možnosť zahrnúť medzery alebo nie.

Výslednú požiadavku tu nebudeme kopírovať, pretože to bude viac ako 4 000 znakov nejedinečného textu prevzatého zo samotného Yandexu, čo je dosť tučné a nepotrebujete to ani vy. Namiesto toho napíšeme jednoduchú PHP slučku, ktorá rýchlo pridá do databázy toľko záznamov, koľko chceme. Na začiatok to bude 100 000 článkov.

Čím menej databázových dotazov, tým lepšie

Už v tejto fáze vám ukážeme bežnú chybu, ktorej sa teraz konkrétne dopustíme my sami.

Pre ($i=1;$i<100000;$i++) { mysql_query("INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Заголовок", "Анонс", "Полный текст")"); }

Ako požiadavku sme prilepili kód skopírovaný z phpmyadmin, ktorý sa zobrazil na obrazovke po jedinom manuálnom pridaní prvého článku. Hneď by som rád poznamenal, že by ste nemali vytvárať dopyty do databázy týmto spôsobom. Urobili sme to len preto, že sme potrebovali rýchlo naplniť tabuľku náhodnými údajmi a tento dotaz sa píše rýchlejšie ako ten, ktorý je optimálnejší. V tejto slučke sme skončili s 99999 samostatnými volaniami databázy (prvé sme urobili manuálne z phpmyadmin), čo je veľmi zlá forma.

Oveľa správnejším riešením by bolo urobiť tú istú operáciu iba pomocou jedného volania databázy a vypísať všetky riadky oddelené čiarkami.

INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Názov", "Oznámenie", "Úplný text"), (NULL, "Názov", "Oznámenie" , "Celý text"), (NULL, "Názov", "Oznámenie", "Celý text"), …

Ak sa vrátime k našej prvej metóde, bude to vyzerať takto:

INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Názov", "Oznámenie", "Celý text") INSERT INTO `test` (`ID`, ` TITLE`, `ANNOUNCEMENT`, `TEXT`) VALUES (NULL, "Title", "Oznámenie", "Celý text") INSERT INTO `test` (`ID`, `TITLE`, `ANNOUNCEMENT`, `TEXT`) HODNOTY (NULL, "Názov", "Oznámenie", "Úplný text") ...

Cítiť rozdiel? Optimálna je možnosť, ktorá využíva iba jeden prístup k databáze. Rýchlosť týchto dvoch metód, vedúca k rovnakému výsledku, sa výrazne líši a je viditeľná bez akýchkoľvek meraní voľným okom, verte mi, je to tak.

Vyberte iba polia požadované skriptom

Všetko je tu veľmi jednoduché - táto alebo tá funkcia potrebuje určité údaje z cieľovej tabuľky. Veľmi často sa ukáže, že musíte vytiahnuť všetky polia vo všeobecnosti, najmä ak je stôl dosť veľký a týchto polí je viac ako 10.

VYBERTE * Z „testu“.

V tomto dotaze hviezdička znamená, že údaje budú načítané zo všetkých polí testovacej tabuľky. Ale čo ak je v tabuľke 20-30 alebo viac týchto polí? Scenár s najväčšou pravdepodobnosťou potrebuje len niektoré z nich a všetky ostatné, ktoré sa nijako nevyužijú, vyberie márne. Takáto operácia bude pomalšia, ako keby ste zadali iba tie polia, ktoré momentálne skutočne potrebujete, oddelené čiarkami.

VYBERTE „ID“, „TITLE“ Z „testu“.

V tomto príklade sa vôbec nedotkneme oznamu a úplného znenia článku, čo výrazne urýchli skript. Dospeli sme teda k záveru, že optimalizácia databázových dotazov znamená aj špecifické označenie požadovaných polí v dotazoch a odmietnutie univerzálnosti v podobe hviezdičky.

Spojenie viacerých dopytov do jedného

Už sme s vami diskutovali o tom, že dobrá optimalizácia práce s mySQL zahŕňa použitie minimálneho možného počtu dopytov a uviedli sme príklad s pridávaním údajov do tabuľky.

Okrem pridávania sa táto technika môže a mala by sa použiť pri vzorkovaní údajov. Teraz si uveďme najjednoduchší príklad. Predstavte si, že máte v databáze dve tabuľky – prvá obsahuje informácie o registrovaných užívateľoch a druhá obsahuje články napísané týmito užívateľmi.

Povedzme, že potrebujete zobraziť nejaký náhodný článok na obrazovke a podpísať ho menom autora v spodnej časti. Vzťah medzi tabuľkami je v tomto prípade zrejmý a vyskytuje sa podľa ID používateľa, t.j. ID používateľa v tabuľke používateľov sa musí zhodovať s poľom USER_ID v tabuľke príspevkov. Toto spojenie je štandardné a malo by byť jasné každému bez výnimky.

Ak chcete vybrať náhodný článok, napíšte dotaz, ako je tento:

$rs_post = mysql_query("SELECT `ID`, `USER_ID`, `TITLE`, `TEXT` FROM `posts` ORDER by RAND() LIMIT 1");

Jeden článok bude náhodne vybraný z tabuľky príspevkov. Potom budú naše akcie vyzerať asi takto:

$row_post = mysql_fetch_assoc($rs_post); $userID = $row_post["USER_ID"];

Teraz premenná $userID obsahuje ID používateľa, ktorý je autorom tohto článku, a aby ste získali jeho údaje, napríklad MENO (krstné meno) a PRIEZVISKO (priezvisko), získate prístup k tabuľke používateľov a dotazu bude vyzerať nejako takto:

$rs_user = mysql_query("SELECT `NAME`, `PRIMENO` FROM `users` WHERE `ID` = "".$row_post["USER_ID"]."" LIMIT 1");

Mimochodom, nezabudnite zarámovať premenné v požiadavkách pomocou jednoduchých úvodzoviek, najmä ak údaje pochádzajú zvonku, pomocou GET alebo POST. To vytvorí ďalšiu bariéru pre útočníkov a je to jedno z opatrení zameraných na ochranu pred SQL injection. Takže späť k nášmu príkladu. Po zadaní požiadavky do databázy je všetko jednoduché - získame meno a priezvisko a zobrazíme ich ako podpis k článku. Misia splnená.

Tieto dva dotazy však možno optimalizovať tak, že ich zmeníte na jeden. Na tento účel použijeme konštrukciu LEFT JOIN:

SELECT `posts`.`ID`, `posts`.`USER_ID`, `posts`.`TITLE`, `posts`.`TEXT`, `users`.`NAME`, `users`.`PRIMENO` FROM ` posts` LEFT JOIN `users` ON ​​`príspevky`.`USER_ID` = `users`.`ID` ORDER by RAND() LIMIT 1

Ako vidíte, vo vyššie uvedenej konštrukcii nie je nič zložité a všetko je intuitívne. Jediné, na čo by som vás chcel upozorniť, je explicitné označenie tabuliek spárovaných s poľami, keďže existuje výber z viacerých tabuliek naraz. Ak sú názvy niektorých polí rovnaké, potom by ste mali použiť takzvané mySQL aliasy, aby ste sa neskôr pri zobrazovaní výsledku nezmiatli.

Záver

Ako vidíte, databázové dotazy môžu a mali by byť optimalizované. Ak si myslíte, že keď vám všetko ide tak rýchlo, tak nemá zmysel nič meniť, počkajte, kým sa databáza vašej stránky niekoľkonásobne rozrastie a spolu s ňou porastie aj návštevnosť. Vyššia návštevnosť znamená častejší súčasný prístup do databázy, ktorej veľkosť ovplyvňuje aj rýchlosť operácií.

Zlá optimalizácia dotazov sa môže prejaviť o niečo neskôr, keď sa stránka dostatočne rozrastie a postupom času bude čoraz ťažšie robiť zmeny, pretože veľkosti súborov a počet funkcií sa len zväčšuje. Na stránku sú pridané nové funkcie zamerané na pohodlie používateľov. Inými slovami, ak sa veci dostanú k určitému bodu varu, možno nebude možné nájsť žiadny koniec a optimalizácia všetkých databázových volaní roztrúsených v stovkách súborov bude trvať niekoľko dní alebo možno týždňov. Preto je lepšie okamžite sa pokúsiť urobiť dobre, aby ste si v budúcnosti nevytvorili zbytočné problémy.

Niekedy pri vytváraní dotazu už viete, že potrebujete iba jeden jedinečný riadok v tabuľke. Môžete vytvoriť výber na základe jedinečného záznamu. Alebo môžete jednoducho spustiť kontrolu existencie ľubovoľného počtu záznamov, ktoré spĺňajú vašu podmienku.

V takýchto prípadoch môže použitie metódy LIMIT 1 výrazne zlepšiť výkon:

// obsahuje databáza ľudí z Kalifornie? // NIE, žiadne nie sú!: $r = mysql_query("SELECT * FROM user WHERE state = "Kalifornia""); if (mysql_num_rows($r) > 0) ( // ... iný kód ) // Áno $r = mysql_query("SELECT 1 FROM user WHERE state = "Kalifornia" LIMIT 1"); if (mysql_num_rows($r) > 0) ( // ... iný kód )

2. Optimalizácia práce s databázou spracovaním cache požiadaviek

Väčšina serverov MySQL podporuje funkciu ukladania dotazov do vyrovnávacej pamäte. Toto je jedno z najefektívnejších vylepšení výkonu, ktoré databázový nástroj zvláda bez problémov.

Keď sa rovnaký dotaz vykoná viackrát, výsledok sa načíta z vyrovnávacej pamäte. Bez toho, aby ste museli znova spracovávať všetky tabuľky. To značne urýchľuje proces.

// ak cache dopytov NIE JE podporovaná $r = mysql_query("VYBERTE meno používateľa FROM user WHERE signup_date >= CURDATE()"); // podporovaná vyrovnávacia pamäť! $dnes_date = datum("R-m-d"); $r = mysql_query("VYBERTE meno používateľa FROM user WHERE signup_date >= "$today_date"");

3. Indexovanie vyhľadávacích polí

Indexy nie sú určené len na priradenie primárnym alebo jedinečným kľúčom. Ak sa v tabuľke nachádzajú stĺpce, ktoré hľadáte, je takmer povinné ich indexovať.

Ako ste pochopili, toto pravidlo platí aj pre časť hľadaného reťazca: ako napríklad "priezvisko LIKE '%'". Pri vyhľadávaní na začiatku riadku môže MySQL použiť index v tomto stĺpci.

Musíte tiež pochopiť, aké druhy dopytov bežné indexy nemôžu používať. Napríklad pri hľadaní slova (napríklad "WHERE post_content LIKE '%tomato%"") vám použitie bežného indexu nebude fungovať. V takom prípade je lepšie použiť vyhľadávanie s úplnou zhodou MySQL alebo si vytvoriť vlastný index.

4. Indexovanie a používanie stĺpcov rovnakého typu pri spájaní

Ak vaša aplikácia obsahuje veľa žiadostí o spojenie, musíte sa uistiť, že stĺpce v oboch tabuľkách, ku ktorým sa pripájate, sú indexované. To ovplyvňuje optimalizáciu interných operácií spájania MySQL.

Tiež stĺpce, ktoré sú zlúčené, musia byť rovnakého typu. Ak napríklad spojíte stĺpec DECIMAL z jednej tabuľky a stĺpec INT z inej, MySQL nebude môcť použiť aspoň jeden z indexov.

Dokonca aj kódovanie znakov musí byť rovnakého typu pre zodpovedajúce reťazce stĺpcov, ktoré sa spájajú.

// hľadám spoločnosti v mojom štáte $r = mysql_query("VYBERTE názov spoločnosti FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id"); // oba stĺpce stavu musia byť indexované // a oba musia byť rovnakého typu a musia mať rovnaké kódovanie znakov pre príslušné riadky // inak bude musieť MySQL prehľadať celú tabuľku

5. Ak je to možné, nepoužívajte dopyty ako SELECT *

Čím viac údajov v tabuľke sa počas dotazu spracuje, tým pomalší bude samotný dotaz. Čas sa stráca na diskové operácie. Taktiež, keď je databázový server oddelený od webového servera, dochádza k oneskoreniam pri prenose údajov medzi servermi.

// nechcený dotaz $r = mysql_query("SELECT * FROM user WHERE user_id = 1"); $d = mysql_fetch_assoc($r); echo "Vitajte ($d["používateľské meno"])"; // je lepšie použiť nasledujúci kód: $r = mysql_query("SELECT username FROM user WHERE user_id = 1"); $d = mysql_fetch_assoc($r); echo "Vitajte ($d["používateľské meno"])";

6. Prosím nepoužívajte metódu triedenia ORDER BY RAND().

Toto je jeden z tých trikov, ktoré sa na prvý pohľad javia ako dobrý nápad a mnohí začínajúci programátori sa do tejto pasce chytia. Nemáte potuchy, akú pascu ste si na seba nachystali hneď, ako začnete tento filter používať v dopytoch.

Ak skutočne potrebujete triediť niektoré reťazce vo výsledkoch vyhľadávania, existujú oveľa efektívnejšie spôsoby, ako to urobiť. Povedzme, že potrebujete pridať ďalší kód do dotazu, ale kvôli tejto pasci to nebudete môcť urobiť, čo zníži efektivitu spracovania údajov s rastúcou veľkosťou databázy.

Problém je v tom, že MySQL vykoná operáciu RAND() (ktorá využíva výpočtové zdroje servera) pred triedením pre každý riadok v tabuľke. V tomto prípade sa vyberie iba jeden riadok.

// ktorý kód NESMIE byť použitý: $r = mysql_query("VYBERTE meno používateľa FROM user ORDER BY RAND() LIMIT 1"); // správnejšie by bolo použiť nasledujúci kód: $r = mysql_query("SELECT count(*) FROM user"); $d = mysql_fetch_row($r); $rand = mt_rand(0,$d - 1); $r = mysql_query("VYBERTE meno používateľa Z LIMITU používateľov $rand, 1");

Vyberiete tak menej výsledkov vyhľadávania, potom môžete použiť metódu LIMIT popísanú v bode 1.

7. Namiesto VARCHAR použite stĺpce ENUM

Stĺpce ENUM sú veľmi kompaktné, a preto sa rýchlo spracovávajú. Vo vnútri databázy je ich obsah uložený vo formáte TINYINT, ale môžu obsahovať a zobrazovať ľubovoľné hodnoty. Preto je veľmi vhodné v nich nastaviť určité polia.

Ak máte nejaké pole, ktoré obsahuje niekoľko rôznych hodnôt rovnakého druhu, potom je lepšie použiť ENUM namiesto stĺpcov VARCHAR. Môže to byť napríklad stĺpec Stav, ktorý obsahuje iba hodnoty ako „aktívny“, „neaktívny“, „čakajúci“, „ platnosť vypršala" atď.

Dokonca je možné nastaviť skript, v ktorom MySQL „vyzve“ na zmenu štruktúry tabuľky. Keď máte pole VARCHAR, systém môže automaticky odporučiť zmenu formátu stĺpca na ENUM. Dá sa to urobiť volaním funkcie PROCEDURE ANALYSE().

Na uloženie adries IP použite polia UNSIGNED INT

Mnoho vývojárov vytvára na tento účel polia ako VARCHAR (15), zatiaľ čo adresy IP môžu byť uložené v databáze ako desatinné čísla. Polia typu INT poskytujú možnosť uložiť až 4 bajty informácií a zároveň je pre ne možné nastaviť pevnú veľkosť poľa.

Musíte sa uistiť, že vaše stĺpce sú vo formáte UNSIGNED INT, pretože adresa IP je špecifikovaná v 32 bitoch.

V dotazoch môžete použiť voľbu INET_ATON() na konverziu IP adries na desatinné čísla a INET_NTOA() na opak. PHP má ďalšie podobné funkcie long2ip() a ip2long().

8. Vertikálne rezy (oddelenie)

Vertikálne rozdelenie je proces vertikálneho rozdelenia štruktúry tabuľky na optimalizáciu výkonu databázy.

Príklad 1: Povedzme, že máte tabuľku používateľov, ktorá okrem iného obsahuje ich domácu adresu. Tieto informácie sa používajú veľmi zriedka. Tabuľku môžete rozdeliť a údaje adresy uložiť do inej tabuľky.

Vaša hlavná používateľská tabuľka sa tak výrazne zmenší. A ako viete, menšie tabuľky sa spracúvajú rýchlejšie.

Príklad 2: V tabuľke máte pole „last_login“ (Posledné prihlásenie). Aktualizuje sa vždy, keď sa používateľ prihlási pomocou svojho používateľského mena. Ale každá zmena tabuľky sa zapíše do vyrovnávacej pamäte dotazov pre túto tabuľku, ktorá je uložená na disku. Toto pole môžete presunúť do inej tabuľky, aby ste znížili počet prístupov vo svojej hlavnej tabuľke používateľov.

Musíte si však byť istí, že obe tabuľky, ktoré sú výsledkom delenia, sa v budúcnosti nebudú používať rovnako často. V opačnom prípade to výrazne zníži výkon.

9. Menšie kolóny sú rýchlejšie

Pre databázové stroje je možno prekážkou priestor na disku. Preto kompaktnejšie ukladanie informácií je zvyčajne výhodné z hľadiska výkonu. Tým sa zníži počet prístupov na disk.

Dokumenty MySQL majú množstvo požiadaviek na úložisko pre rôzne typy údajov. Ak sa neočakáva, že tabuľka bude obsahovať príliš veľa záznamov, potom nie je dôvod ukladať primárny kľúč do polí typu INT, MEDIUMINT, SMALLINT a v niektorých prípadoch dokonca TINYINT. Ak nepotrebujete časové komponenty (hodiny:minúty) vo formáte dátumu, použite polia typu DATE namiesto DATETIME.

Dbajte však na to, aby ste si v budúcnosti nechali dostatok priestoru na rozvoj. V opačnom prípade môže v určitom okamihu nastať niečo ako kolaps.