Vývojári SQL na každej platforme bojujú, zdanlivo uviazli v UROBTE PRI ČOM slučka, ktorá ich núti opakovať stále tie isté chyby. Je to preto, že pole databázy je stále pomerne nezrelé. Iste, predajcovia robia určité pokroky, ale naďalej zápasia s väčšími problémami. Súbežnosť, správa zdrojov, správa priestoru a rýchlosť stále trápia vývojárov SQL, či už kódujú na serveroch SQL Server, Oracle, DB2, Sybase, MySQL alebo na akejkoľvek inej relačnej platforme.
Čiastočný problém spočíva v tom, že neexistuje žiadna magická guľka a pri takmer každom najlepšom postupe vám môžem ukázať aspoň jednu výnimku. Vývojár zvyčajne nájde svoje vlastné obľúbené metódy - aj keď zvyčajne neobsahujú žiadne konštrukty pre výkon alebo súbežnosť - a neobťažuje sa preskúmaním ďalších možností. Možno je to príznak nedostatku vzdelania, alebo sú vývojári príliš blízko procesu, aby rozpoznali, keď robia niečo zlé. Možno dotaz funguje dobre na miestnej sade testovacích údajov, ale vo výrobnom systéme zlyhá.
Neočakávam, že sa z vývojárov SQL stanú správcovia, ale pri písaní kódu musia brať do úvahy produkčné problémy. Ak to neurobia počas počiatočného vývoja, DBA ich prinúti vrátiť sa a urobiť to neskôr - a používatelia budú dočasne trpieť.
Existuje dôvod, prečo hovoríme, že vyladenie databázy je umenie aj veda. Je to preto, lebo plošne existuje len veľmi málo prísnych pravidiel. Problémy, ktoré ste vyriešili v jednom systéme, nie sú problémami v inom systéme a naopak. Pokiaľ ide o vyladenie dotazov, neexistuje správna odpoveď, to však neznamená, že by ste sa mali vzdať.
Existuje niekoľko dobrých zásad, ktoré môžete dodržiavať, ktoré by mali priniesť výsledky v tej či onej kombinácii. Zapísal som ich do zoznamu príkazov SQL a vecí, ktoré sa často prehliadajú alebo ťažko spozorujú. Tieto techniky by vám mali poskytnúť trochu viac informácií o mysliach vašich DBA, ako aj schopnosť začať myslieť na procesy výrobne orientovaným spôsobom.
1. Nepoužívajte AKTUALIZÁCIA namiesto PRÍPAD
Tento problém je veľmi častý a hoci ho nie je ťažké spoznať, mnoho vývojárov ho často prehliada, pretože používa AKTUALIZÁCIA má prirodzenú vlastnosť, ktorá sa zdá byť logická.
Vezmime si napríklad tento scenár: Vkladáte údaje do dočasnej tabuľky a potrebujete ich, aby zobrazovali určitú hodnotu, ak existuje iná. Možno ťaháte od tabuľky zákazníkov a chcete, aby bol ktokoľvek s objednávkami nad 100 000 dolárov označený ako „Preferovaný“. Takto vložíte údaje do tabuľky a spustíte znak AKTUALIZÁCIA vyhlásenie pre nastavenie stĺpca CustomerRank na „Preferované“ pre každého, kto má v objednávkach viac ako 100 000 dolárov. Problém je v tom, že AKTUALIZÁCIA výpis je zaprotokolovaný, čo znamená, že musí písať dvakrát za každý jeden zápis do tabuľky. Cesta okolo toho, samozrejme, je použitie vloženého riadku PRÍPAD príkaz v samotnom dotaze SQL. Týmto sa v každom riadku otestuje podmienka množstva objednávky a pred zapísaním do tabuľky sa nastaví štítok „Preferované“. Zvýšenie výkonu môže byť ohromujúce.
2. Nepoužívajte slepo opakovane kód
Táto otázka je tiež veľmi častá. Kopírovanie kódu niekoho iného je veľmi jednoduché, pretože viete, že získava potrebné údaje. Problém je v tom, že pomerne často stiahne oveľa viac údajov, ako potrebujete, a vývojári sa zriedka obťažujú ich orezávanie, takže nakoniec dostanú obrovskú nadmnožinu údajov. To zvyčajne prichádza vo forme extra vonkajšieho spojenia alebo extra stavu v KDE doložka. Obrovský nárast výkonu môžete dosiahnuť, ak upravený kód upravíte podľa svojich presných potrieb.
3. Vytiahnite iba taký počet stĺpcov, aký potrebujete
Toto vydanie je podobné číslu 2, ale je špecifické pre stĺpce. Je príliš ľahké kódovať všetky vaše dotazy VYBERTE * namiesto samostatného výpisu stĺpcov. Problém je opäť v tom, že získava viac údajov, ako potrebujete. Túto chybu som videl už desiatkykrát. Vývojár robí a VYBERTE * dopytovať proti tabuľke so 120 stĺpcami a miliónmi riadkov, ale nakoniec použije iba tri až päť z nich. V tom okamihu spracovávate oveľa viac údajov, ako potrebujete. Je prekvapujúce, že sa dopyt vôbec vráti. Spracúvate nielen viac údajov, ako potrebujete, ale aj beriete zdroje z iných procesov.
4. Nenamáčajte to dvakrát
Tu je ďalší, ktorý som už videl viackrát, ako by som mal: Uložená procedúra je napísaná na vytiahnutie údajov z tabuľky so stovkami miliónov riadkov. Developer potrebuje zákazníkov, ktorí žijú v Kalifornii a majú príjmy viac ako 40 000 dolárov. Dotáže sa teda zákazníkov, ktorí žijú v Kalifornii, a výsledky umiestni do dočasnej tabuľky; potom vyhľadá dopyt u zákazníkov s príjmami nad 40 000 dolárov a tieto výsledky umiestni do inej dočasnej tabuľky. Nakoniec sa pripojí k obidvom stolom, aby získal konečný produkt.
Robíš si zo mňa srandu? Toto by sa malo vykonať v jednom dotaze; namiesto toho dvakrát namáčate veľkú tabuľku. Nebuďte hlupák: Dotazujte sa veľkých tabuliek iba raz, kedykoľvek je to možné - zistíte, o koľko lepšie sú vaše postupy.
Trochu odlišný scenár je, keď podmnožinu veľkej tabuľky vyžaduje niekoľko krokov procesu, čo spôsobí, že sa na veľkú tabuľku bude dopytovať zakaždým. Vyhnite sa tomu tak, že zadáte dotaz na podmnožinu a vytrváte ju inde, potom nasmerujete nasledujúce kroky na svoju menšiu množinu údajov.
6. Robte predstupňové údaje
Toto je jedna z mojich obľúbených tém, pretože je to stará technika, ktorá sa často prehliada. Ak máte správu alebo postup (alebo ešte lepšie ich sadu), ktorý bude robiť podobné spojenia s veľkými tabuľkami, môže byť pre vás výhodou vopred pripraviť údaje spojením tabuliek v predstihu a ich pretrvaním. do stola. Teraz môžu prehľady bežať proti tejto vopred pripravenej tabuľke a vyhnúť sa veľkému spojeniu.
Nie vždy môžete túto techniku použiť, ale ak budete môcť, zistíte, že je to vynikajúci spôsob, ako šetriť zdroje servera.
Upozorňujeme, že mnoho vývojárov tento problém so spojením obchádza tak, že sa sústredí na samotný dotaz a vytvorí okolo spojenia iba zobrazenie, aby nemuseli znova a znova zadávať podmienky spojenia. Ale problém s týmto prístupom je, že dotaz stále beží pre každú správu, ktorá to potrebuje. Predbežným nastavením údajov spustíte spojenie iba raz (povedzme 10 minút pred prehľadmi) a všetci ostatní sa veľkému spojeniu vyhnú. Nemôžem vám povedať, ako veľmi milujem túto techniku; vo väčšine prostredí existujú populárne tabuľky, ktoré sa neustále spájajú, takže nie je dôvod, prečo ich nemožno vopred pripraviť.
7. Odstráňte a aktualizujte dávky
Je tu ďalšia jednoduchá technika, ktorá sa často prehliada. Ak to neurobíte správne, môže byť vymazanie alebo aktualizácia veľkého množstva údajov z obrovských tabuliek nočnou morou. Problém je v tom, že oba tieto príkazy fungujú ako jedna transakcia. Ak ich potrebujete zabiť alebo ak sa niečo stane systému, kým pracujú, musí systém vrátiť celú transakciu späť. Môže to trvať veľmi dlho. Tieto operácie môžu tiež blokovať ďalšie transakcie po dobu ich trvania, čo v zásade predstavuje problémové miesto v systéme.
Riešením je odstránenie alebo aktualizácie v menších dávkach. Týmto sa váš problém vyrieši niekoľkými spôsobmi. Po prvé, ak dôjde k zabitiu transakcie z akéhokoľvek dôvodu, má iba malý počet riadkov na vrátenie späť, takže databáza sa vráti online oveľa rýchlejšie. Po druhé, zatiaľ čo sa menšie dávky zaväzujú na disk, iné sa môžu vkradnúť a vykonať určitú prácu, takže súbežnosť je výrazne vylepšená.
V tejto súvislosti má mnoho vývojárov uviaznutých v hlavách, že tieto operácie odstraňovania a aktualizácie musia byť dokončené v ten istý deň. Nie vždy to platí, najmä ak archivujete. Túto operáciu môžete natiahnuť tak dlho, ako potrebujete, a menšie dávky to pomôžu dosiahnuť. Ak vám tieto intenzívne operácie môžu trvať dlhšie, strávte čas navyše a neznižujte svoj systém.
8. Používajte dočasné tabuľky na zlepšenie výkonu kurzora
Dúfam, že už všetci vieme, že je najlepšie držať sa od kurzorov, pokiaľ je to možné. Kurzory nielenže trpia problémami s rýchlosťou, ktoré samy o sebe môžu byť problémom mnohých operácií, ale môžu tiež spôsobiť, že vaša operácia zablokuje ďalšie operácie na oveľa dlhšie, než je potrebné. To výrazne znižuje súbežnosť vo vašom systéme.
Nie vždy sa však môžete vyhnúť použitiu kurzorov a keď tieto časy nastanú, budete sa pravdepodobne môcť dostať preč od problémov s výkonom vyvolaných kurzorom tak, že namiesto nich urobíte operácie kurzora s dočasnou tabuľkou. Vezmime si napríklad kurzor, ktorý prechádza tabuľkou a na základe niektorých výsledkov porovnania aktualizuje niekoľko stĺpcov. Namiesto porovnania so zverejnenou tabuľkou môžete tieto údaje vložiť do dočasnej tabuľky a namiesto toho vykonať porovnanie. Potom máte singel AKTUALIZÁCIA vyhlásenie proti živému stolu, ktorý je oveľa menší a drží zámky iba na krátky čas.
Takéto úpravy údajov môžu výrazne zvýšiť súbežnosť. Na záver chcem povedať, že takmer nikdy nemusíte používať kurzor. Takmer vždy existuje riešenie založené na množinách; treba sa to naučiť vidieť.
9. Nevkladajte pohľady
Pohľady môžu byť pohodlné, ale pri ich používaní musíte byť opatrní. Aj keď zobrazenia môžu pomôcť zakryť veľké dotazy používateľov a štandardizovať prístup k údajom, môžete sa ľahko ocitnúť v situácii, keď máte zobrazenia, ktoré volajú zobrazenia, ktoré volajú zobrazenia, ktoré volajú zobrazenia. Toto sa volá hniezdiace pohľady, a to môže spôsobiť vážne problémy s výkonom, najmä dvoma spôsobmi:
- Po prvé, s najväčšou pravdepodobnosťou sa budete vracať oveľa viac údajov, ako potrebujete.
- Po druhé, optimalizátor dotazov sa vzdá a vráti plán zlých dotazov.
Raz som mal klienta, ktorý miloval hniezdiace výhľady. Klient mal jeden pohľad, ktorý používal takmer na všetko, pretože mal dve dôležité spojenia. Problém bol v tom, že zobrazenie vrátilo stĺpec, v ktorom boli 2 MB dokumenty. Niektoré dokumenty boli ešte väčšie. Klient tlačil do siete minimálne ďalšie 2 MB pre každý jeden riadok takmer v každom jednom spustenom dotaze. Výkon dotazov bol prirodzene priepastný.
A žiadny z dotazov v skutočnosti nepoužil tento stĺpec! Samozrejme, stĺp bol zakopaný v hĺbke siedmich pohľadov, takže aj hľadanie bolo ťažké. Keď som odstránil stĺpec dokumentu zo zobrazenia, čas pre najväčší dopyt išiel z 2,5 hodiny na 10 minút. Keď som konečne rozlúštil vnorené pohľady, ktoré mali niekoľko zbytočných spojení a stĺpcov, a napísal obyčajný dotaz, čas pre ten istý dotaz klesol na subsekundy.
