Kiekvienos platformos SQL kūrėjai stengiasi, atrodo, įstrigę Daryk, kol kilpa, dėl kurios jie vėl ir vėl kartoja tas pačias klaidas. Taip yra todėl, kad duomenų bazės laukas vis dar yra palyginti nebrandus. Aišku, pardavėjai žengia šiek tiek žingsnių, tačiau jie ir toliau grumiasi su didesnėmis problemomis. Lygiagretumas, išteklių valdymas, erdvės valdymas ir greitis vis tiek kankina SQL kūrėjus, nesvarbu, ar jie koduoja SQL Server, Oracle, DB2, Sybase, MySQL ar bet kurią kitą reliacinę platformą.
Dalis problemos yra ta, kad nėra stebuklingos kulkos, ir beveik kiekvienai gerajai praktikai galiu parodyti bent vieną išimtį. Paprastai kūrėjas randa savo mėgstamus metodus, nors paprastai juose nėra jokių atlikimo ar sutapimo konstrukcijų, ir nesivargina tyrinėdamas kitas galimybes. Galbūt tai yra nepakankamo išsilavinimo simptomas, arba kūrėjai yra per daug arti proceso, kad atpažintų, kai daro kažką ne taip. Galbūt užklausa gerai vykdoma naudojant vietinį bandymo duomenų rinkinį, tačiau gamybos sistemoje nepavyksta.
Nesitikiu, kad SQL kūrėjai taps administratoriais, tačiau rašydami kodą jie turi atsižvelgti į gamybos problemas. Jei jie to nepadarys pradinio kūrimo metu, DBA tiesiog privers juos grįžti atgal ir tai padaryti vėliau, o vartotojai kenčia nuo to laiko.
Yra priežastis, kodėl mes sakome, kad duomenų bazės derinimas yra ir menas, ir mokslas. Taip yra todėl, kad egzistuoja labai nedaug griežtų taisyklių, galiojančių visoje erdvėje. Problemos, kurias išsprendėte vienoje sistemoje, nėra kitos problemos ir atvirkščiai. Nėra teisingo atsakymo, kai reikia derinti užklausas, tačiau tai nereiškia, kad turėtumėte pasiduoti.
Yra keletas gerų principų, kurių galite laikytis ir kurie turėtų duoti rezultatų viename ar kitame derinyje. Aš juos sutalpinau į SQL dokumentų ir draudimų sąrašą, kurie dažnai būna nepastebimi ar sunkiai pastebimi. Šie metodai turėtų suteikti jums šiek tiek daugiau supratimo apie savo DBA mintis ir galimybę pradėti galvoti apie procesus į gamybą.
1. Nenaudokite ATNAUJINTI vietoj ATVEJIS
Ši problema yra labai dažna, ir nors tai nėra sunku pastebėti, daugelis kūrėjų dažnai nepaiso, nes naudoja ATNAUJINTI turi natūralią skolą, kuri atrodo logiška.
Paimkite, pavyzdžiui, šį scenarijų: įterpiate duomenis į temp lentelę ir jums reikia, kad jie rodytų tam tikrą vertę, jei yra kita reikšmė. Galbūt traukiatės iš kliento stalo ir norite, kad visi, turintys daugiau nei 100 000 USD užsakymų, būtų pažymėti kaip „Pageidaujami“. Taigi, jūs įterpiate duomenis į lentelę ir paleidžiate ATNAUJINTI pareiškimą, kad nustatytumėte „CustomerRank“ stulpelį į „Pageidaujamas“ tiems, kurie turi daugiau nei 100 000 USD užsakymų. Problema ta, kad ATNAUJINTI pareiškimas yra užregistruotas, o tai reiškia, kad jis turi parašyti du kartus už kiekvieną įrašą į lentelę. Žinoma, tai reikia naudoti įterptiniu būdu ATVEJIS sakinį pačioje SQL užklausoje. Kiekvienoje eilutėje patikrinama užsakymo sumos sąlyga ir nustatoma etiketė „Pageidaujama“, kol ji neparašyta prie lentelės. Veiklos padidėjimas gali būti stulbinantis.
2. Nenaudokite aklai pakartotinai kodo
Šis klausimas taip pat yra labai dažnas. Labai lengva nukopijuoti kažkieno kodą, nes žinote, kad jis ištraukia jums reikalingus duomenis. Problema ta, kad gana dažnai tai surenka daug daugiau duomenų, nei jums reikia, ir kūrėjai retai stengiasi juos apkirpti, todėl jie gauna didžiulį duomenų rinkinį. Paprastai tai yra papildoma išorinė jungtis arba papildoma sąlyga KUR sąlyga. Galite patobulinti našumą, jei pakartotinai naudojamą kodą sutvarkysite pagal savo tikslius poreikius.
3. Traukite tik jums reikalingą stulpelių skaičių
Ši problema yra panaši į 2 numerį, tačiau ji skirta stulpeliams. Per lengva koduoti visas savo užklausas PASIRINKTI * užuot pateikę stulpelius atskirai. Vėlgi problema yra ta, kad ji surenka daugiau duomenų, nei jums reikia. Šią klaidą mačiau keliasdešimt kartų. Kūrėjas daro a PASIRINKTI * užklausa prieš lentelę su 120 stulpelių ir milijonais eilučių, tačiau baigiama naudojant tik tris – penkias iš jų. Tuo metu apdorojate tiek daug duomenų, kiek jums reikia, stebėtina, kad užklausa apskritai grįžta. Apdorojate ne tik daugiau duomenų, nei jums reikia, bet ir atimate išteklius iš kitų procesų.
4. Negalima dvigubai panardinti
Čia yra dar vienas, kurį mačiau daugiau kartų, nei turėjau turėti: Parašyta saugoma procedūra, skirta ištraukti duomenis iš lentelės su šimtais milijonų eilučių. Kūrėjui reikia klientų, kurie gyvena Kalifornijoje ir kurių pajamos viršija 40 000 USD. Taigi jis klausia klientų, gyvenančių Kalifornijoje, ir pateikia rezultatus į temp lentelę; tada jis klausia klientų, kurių pajamos viršija 40 000 USD, ir pateikia šiuos rezultatus į kitą temp lentelę. Galiausiai jis prisijungia prie abiejų lentelių, kad gautų galutinį produktą.
Ar tu juokauji? Tai turėtų būti padaryta vienoje užklausoje; vietoj to jūs dvigubai panardinate itin didelį stalą. Nebūk debilas: jei įmanoma, paklauskite didelių stalų tik vieną kartą - sužinosite, kiek geriau atliekamos jūsų procedūros.
Šiek tiek kitoks scenarijus yra tada, kai keliems proceso etapams reikalingas didelės lentelės pogrupis, dėl kurio didelę lentelę reikia paklausti kiekvieną kartą. Venkite to užklausdami pogrupį ir palikdami jį kitur, tada nurodydami tolesnius veiksmus į mažesnį duomenų rinkinį.
6. Atlikite išankstinius duomenis
Tai viena iš mano mėgstamiausių temų, nes tai sena technika, į kurią dažnai neatsižvelgiama. Jei turite ataskaitą ar procedūrą (arba dar geriau - jų rinkinį), kuri atliks panašius sujungimus su didelėmis lentelėmis, jums gali būti naudinga iš anksto suplanuoti duomenis, prieš laiką sujungiant lenteles ir jas palaikant. į stalą. Dabar ataskaitos gali būti vykdomos prieš tą iš anksto parengtą lentelę ir išvengti didelio prisijungimo.
Ne visada galite naudoti šią techniką, tačiau kai tik galite, rasite tai puikus būdas taupyti serverio išteklius.
Atminkite, kad daugelis kūrėjų išsprendžia šią prisijungimo problemą, sutelkdami dėmesį į pačią užklausą ir sukurdami tik sujungimo rodinį, kad nereikėtų vėl ir vėl įvesti prisijungimo sąlygų. Tačiau šio požiūrio problema yra ta, kad užklausa vis tiek vykdoma kiekvienoje ataskaitoje, kuriai to reikia. Iš anksto nustatydami duomenis, jūs paleidžiate prisijungimą tik vieną kartą (tarkime, likus 10 minučių iki ataskaitų), o visi kiti išvengia didelio prisijungimo. Negaliu pasakyti, kaip aš myliu šią techniką; daugumoje aplinkų yra populiarios lentelės, prie kurių nuolat prisijungiama, todėl nėra jokios priežasties, kodėl jų negalima iš anksto surengti.
7. Ištrinkite ir atnaujinkite paketais
Štai dar viena lengva technika, kurios labai nepaisoma. Didelio duomenų kiekio ištrynimas ar atnaujinimas iš didžiulių lentelių gali būti košmaras, jei to nepadarote tinkamai. Problema ta, kad abu šie teiginiai vykdomi kaip viena operacija, ir jei jums reikia juos nužudyti arba jei sistemai kažkas atsitinka, kai jie veikia, sistema turi grąžinti visą operaciją. Tai gali užtrukti labai ilgai. Šios operacijos taip pat gali užblokuoti kitas operacijas dėl jų trukmės, o tai iš esmės trukdo sistemai.
Sprendimas yra ištrinti ar atnaujinti mažesnėmis partijomis. Tai išsprendžia jūsų problemą keliais būdais. Pirma, jei operacija dėl kokių nors priežasčių žudoma, joje galima sugrąžinti tik nedaug eilučių, todėl duomenų bazė grįžta į internetą daug greičiau. Antra, nors mažesnės partijos įpareigoja diską, kitos gali įsilaužti ir atlikti tam tikrą darbą, todėl sutapimas yra žymiai didesnis.
Atsižvelgiant į tai, daugeliui kūrėjų įstrigo mintis, kad šios ištrynimo ir atnaujinimo operacijos turi būti atliktos tą pačią dieną. Tai ne visada tiesa, ypač jei archyvuojate. Tą operaciją galite ištempti tiek, kiek jums reikia, o mažesnės partijos padeda tai pasiekti. Jei galite užtrukti ilgiau, kol atliksite šias intensyvias operacijas, praleiskite papildomą laiką ir nesumažinkite sistemos.
8. Norėdami pagerinti žymeklio našumą, naudokite temp lenteles
Tikiuosi, kad mes visi jau žinome, kad geriausia, jei įmanoma, laikytis atokiau nuo žymeklių. Žymekliai ne tik kenčia nuo greičio problemų, o tai savaime gali būti problema atliekant daugelį operacijų, bet jie taip pat gali sukelti jūsų operacijos blokavimą kitoms operacijoms daug ilgiau nei būtina. Tai labai sumažina sutapimą jūsų sistemoje.
Tačiau ne visada galite išvengti žymeklių naudojimo ir, atėjus šiems laikams, galite atsikratyti žymeklio sukeltų našumo problemų, atlikdami žymeklio operacijas pagal temp lentelę. Paimkime, pavyzdžiui, žymeklį, kuris eina per lentelę ir atnaujina porą stulpelių, remdamasis kai kuriais palyginimo rezultatais. Užuot palyginęs su tiesiogine lentele, galbūt galėsite įdėti tuos duomenis į laikiną lentelę ir palyginti su tuo. Tada turite vienintelį ATNAUJINTI pareiškimas prieš gyvą stalą, kuris yra daug mažesnis ir užraktus laiko tik trumpam.
Tokie duomenų pakeitimai, kaip šis, gali žymiai padidinti sutapimą. Baigsiu pasakydamas, kad beveik niekada nereikia naudoti žymeklio. Beveik visada yra rinkiniu pagrįstas sprendimas; reikia išmokti tai pamatyti.
9. Nestumkite vaizdų
Vaizdai gali būti patogūs, tačiau juos naudojant reikia būti atsargiems. Nors rodiniai gali padėti užgožti dideles vartotojų užklausas ir standartizuoti prieigą prie duomenų, galite lengvai atsidurti situacijoje, kai turite rodinių, kurie skambina rodiniams, kurie skambina rodiniams, kurie skambina rodiniams. Tai vadinama lizdų vaizdai, ir tai gali sukelti rimtų našumo problemų, ypač dviem būdais:
- Pirma, labai tikėtina, kad grįšite daug daugiau duomenų, nei jums reikia.
- Antra, užklausos optimizatorius atsisakys ir pateiks netinkamą užklausos planą.
Kažkada turėjau klientą, kuriam patiko lizdų vaizdai. Klientas turėjo vieną požiūrį, kurį naudojo beveik viskam, nes jis turėjo du svarbius sujungimus. Problema buvo ta, kad rodinys grąžino stulpelį su 2 MB dokumentais. Kai kurie dokumentai buvo dar didesni. Kiekvienoje eilutėje klientas beveik kiekvienoje paleistoje užklausoje stūmė mažiausiai 2 MB tinklo. Natūralu, kad užklausos našumas buvo baisus.
Ir nė viena iš užklausų iš tikrųjų nenaudojo to stulpelio! Žinoma, kolona buvo palaidota septynių vaizdų gylyje, todėl net rasti ją buvo sunku. Kai pašalinau dokumento stulpelį iš rodinio, didžiausios užklausos laikas truko nuo 2,5 valandos iki 10 minučių. Kai pagaliau išnarpliojau įdėtus rodinius, kuriuose buvo keli nereikalingi sujungimai ir stulpeliai, ir parašiau paprastą užklausą, tos pačios užklausos laikas nukrito iki sekundžių.
