SQL-kehittäjät kaikilla alustoilla kamppailevat, näennäisesti jumissa a TEHDÄ, KUN silmukka, joka saa heidät toistamaan samat virheet uudestaan ja uudestaan. Tämä johtuu siitä, että tietokantakenttä on edelleen suhteellisen epäkypsä. Toki, myyjät ovat tekemässä joitain edistysaskeleita, mutta he kamppailevat edelleen suurempien ongelmien kanssa. Samanaikaisuus, resurssien hallinta, tilanhallinta ja nopeus vaivaavat edelleen SQL-kehittäjiä riippumatta siitä, koodaavatko ne SQL Serveriä, Oracle, DB2, Sybase, MySQL tai mitä tahansa muuta relaatioalustaa.
Osa ongelmasta on se, että ei ole maagista luotia, ja voin näyttää jokaiselle parhaalle käytännölle ainakin yhden poikkeuksen. Kehittäjä löytää tyypillisesti omat suosikkimenetelmänsä - vaikka yleensä ne eivät sisällä suoritus- tai samanaikaisrakenteita - eikä vaivaudu tutkimaan muita vaihtoehtoja. Ehkä se on oire koulutuksen puutteesta, tai kehittäjät ovat aivan liian lähellä prosessia tunnistamaan, kun he tekevät jotain väärin. Ehkä kysely toimii hyvin paikallisilla testitiedoilla, mutta epäonnistuu surkeasti tuotantojärjestelmässä.
En usko, että SQL-kehittäjistä tulee järjestelmänvalvojia, mutta heidän on otettava tuotantokysymykset huomioon kirjoittaessaan koodiaan. Jos he eivät tee sitä alkuperäisen kehityksen aikana, DBA: t vain saavat heidät palaamaan takaisin ja tekemään sen myöhemmin - ja käyttäjät kärsivät väliaikaisesti.
Siihen on syy, miksi sanomme, että tietokannan virittäminen on sekä taidetta että tiedettä. Se johtuu siitä, että on olemassa vain vähän kovia ja nopeita sääntöjä, joita sovelletaan kaikkialla. Yhdessä järjestelmässä ratkaisemasi ongelmat eivät aiheuta ongelmia toisessa ja päinvastoin. Kysymysten virittämiseen ei ole oikeaa vastausta, mutta se ei tarkoita, että sinun pitäisi luopua.
Voit noudattaa joitain hyviä periaatteita, joiden pitäisi tuottaa tuloksia yhdessä tai toisessa. Olen koonnut ne luetteloon SQL-asiakirjoista, joita usein unohdetaan tai joita on vaikea havaita. Näiden tekniikoiden pitäisi antaa sinulle hieman enemmän tietoa DBA: n mielestäsi sekä kyky aloittaa prosessien ajattelu tuotantoon suuntautuneella tavalla.
1. Älä käytä PÄIVITTÄÄ sijasta TAPAUS
Tämä ongelma on hyvin yleinen, ja vaikka sitä ei ole vaikea havaita, monet kehittäjät usein unohtavat sen käytön vuoksi PÄIVITTÄÄ on luonnollinen velka, joka näyttää loogiselta.
Käytä esimerkiksi tätä skenaariota: Lisät tietoja väliaikaistaulukkoon ja tarvitset sitä näyttämään tietyn arvon, jos toinen arvo on olemassa. Ehkä vedät asiakastaulukosta ja haluat, että kuka tahansa, jolla on yli 100 000 dollaria tilauksia, merkitään etusijalle. Siten syötät tiedot taulukkoon ja suoritat PÄIVITTÄÄ -lauseke, jolla CustomerRank-sarake asetetaan “Ensisijaiseksi” kaikille, joilla on yli 100 000 dollaria tilauksia. Ongelmana on, että PÄIVITTÄÄ lause on kirjattu, mikä tarkoittaa, että sen on kirjoitettava kahdesti jokaisesta taulukon kirjoituksesta. Tietysti on tietysti käytettävä inline-muotoa TAPAUS SQL-kyselyssä. Tämä testaa jokaisella rivillä tilauksen määrän ehdon ja asettaa "Ensisijainen" -tunnisteen, ennen kuin se kirjoitetaan taulukkoon. Suorituskyvyn kasvu voi olla huikea.
2. Älä käytä koodia sokeasti uudelleen
Tämä asia on myös hyvin yleinen. Joku toisen koodi on erittäin helppo kopioida, koska tiedät, että se vetää tarvitsemasi tiedot. Ongelmana on, että melko usein se vetää paljon enemmän tietoa kuin tarvitset, ja kehittäjät harvoin vaivautuvat sen leikkaamiseen, joten heillä on valtava tietojen joukko. Tämä tapahtuu yleensä ylimääräisen ulomman liitoksen tai lisäehdon muodossa MISSÄ lauseke. Voit saada valtavia suorituskyvyn parannuksia, jos rajaat uudelleenkäytetyn koodin tarkkoihin tarpeisiisi.
3. Vedä vain tarvitsemasi sarakemäärä
Tämä numero on samanlainen kuin numero 2, mutta se koskee vain sarakkeita. Kaikkien kyselyidesi koodaus on aivan liian helppoa VALITSE * sen sijaan, että luetellaan sarakkeet erikseen. Jälleen ongelmana on, että se vetää enemmän tietoa kuin tarvitset. Olen nähnyt tämän virheen kymmeniä ja kymmeniä kertoja. Kehittäjä tekee a VALITSE * kysely taulukkoa vastaan, jossa on 120 saraketta ja miljoonia rivejä, mutta loppuu vain kolmesta viiteen niistä. Tuolloin käsittelet niin paljon enemmän tietoja kuin tarvitset, on ihme, että kysely palaa ollenkaan. Käsittelet paitsi enemmän tietoa kuin tarvitset, mutta otat myös resursseja pois muista prosesseista.
4. Älä upota
Tässä on toinen, jonka olen nähnyt useita kertoja kuin minun olisi pitänyt: Tallennettu toiminto kirjoitetaan tietojen vetämiseksi taulukosta, jossa on satoja miljoonia rivejä. Kehittäjä tarvitsee asiakkaita, jotka asuvat Kaliforniassa ja joiden tulot ovat yli 40 000 dollaria. Joten hän kysyy asiakkailta, jotka asuvat Kaliforniassa, ja laittaa tulokset temp-taulukkoon; sitten hän kysyy asiakkailta, joiden tulot ovat yli 40 000 dollaria, ja laittaa tulokset toiseen temp-taulukkoon. Lopuksi hän liittyy molempiin pöytiin saadakseen lopputuotteen.
Vitsailetko? Tämä tulisi tehdä yhdellä kyselyllä; sen sijaan upotat kaksinkertaisen suuren pöydän. Älä ole debyytti: Kysele suuria pöytiä vain kerran aina kun mahdollista - huomaat kuinka paljon paremmin hoitosi toimivat.
Hieman erilainen skenaario on, kun prosessin useita vaiheita varten tarvitaan suuren taulukon osajoukko, mikä aiheuttaa suuren taulukon kyselyn joka kerta. Vältä tätä tekemällä kysely alijoukolle ja säilyttämällä se muualla ja osoittamalla seuraavat vaiheet pienempään tietojoukkoosi.
6. Tee esivaiheen tiedot
Tämä on yksi suosikkini aiheistani, koska se on vanha tekniikka, joka jätetään usein huomiotta. Jos sinulla on raportti tai menettely (tai vielä parempi, joukko niistä), joka tekee samanlaiset liittymät suuriin taulukoihin, voi olla hyötyä tietojen esivaiheistamisesta liittymällä taulukoihin etuajassa ja ylläpitämällä niitä pöydälle. Nyt raportit voivat toimia kyseistä ennalta lavoitettua taulukkoa vastaan ja välttää suurta liittymistä.
Et voi aina käyttää tätä tekniikkaa, mutta kun voit, huomaat, että se on erinomainen tapa säästää palvelinresursseja.
Huomaa, että monet kehittäjät kiertävät tämän liittymisongelman keskittymällä itse kyselyyn ja luomalla vain näkymän liitoksen ympärille, jotta heidän ei tarvitse kirjoittaa liittymisehtoja uudestaan ja uudestaan. Mutta tämän lähestymistavan ongelmana on, että kysely suoritetaan edelleen jokaiselle sitä tarvitsevalle raportille. Etukäteen vaiheittaiset tiedot suoritat liittymisen vain kerran (esimerkiksi 10 minuuttia ennen raportteja) ja kaikki muut välttävät isoa liittymistä. En voi kertoa kuinka paljon rakastan tätä tekniikkaa; useimmissa ympäristöissä on suosittuja pöytiä, jotka liitetään koko ajan, joten ei ole mitään syytä, miksi niitä ei voida esiasettaa.
7. Poista ja päivitä erissä
Tässä on toinen helppo tekniikka, joka jätetään huomiotta paljon. Suurten tietomäärien poistaminen tai päivittäminen valtavista taulukoista voi olla painajainen, jos et tee sitä oikein. Ongelmana on, että molemmat lauseet suoritetaan yhtenä tapahtumana, ja jos sinun on tapettava ne tai jos järjestelmälle tapahtuu jotain heidän työskennellessään, järjestelmän on palautettava koko tapahtuma. Tämä voi kestää hyvin kauan. Nämä toiminnot voivat myös estää muita tapahtumia niiden keston ajaksi, mikä käytännössä pullottaa järjestelmän.
Ratkaisu on tehdä poistot tai päivitykset pienemmissä erissä. Tämä ratkaisee ongelmasi parilla tavalla. Ensinnäkin, jos tapahtuma tapetaan jostain syystä, sillä on vain pieni määrä rivejä, joita voidaan palata takaisin, joten tietokanta palaa verkossa paljon nopeammin. Toiseksi, vaikka pienemmät erät sitoutuvat levylle, toiset voivat hiipiä sisään ja tehdä töitä, joten samanaikaisuus paranee huomattavasti.
Näillä linjoilla monilla kehittäjillä on juuttunut päähänsä, että nämä poisto- ja päivitystoiminnot on suoritettava samana päivänä. Se ei ole aina totta, varsinkin jos arkistoit. Voit venyttää kyseisen toimenpiteen niin kauan kuin tarvitset, ja pienemmät erät auttavat saavuttamaan sen. Jos voit kestää kauemmin näiden intensiivisten toimintojen suorittamiseen, vie ylimääräinen aika äläkä pudota järjestelmääsi.
8. Käytä temp-taulukoita parantaaksesi kohdistimen suorituskykyä
Toivon, että me kaikki tiedämme jo nyt, että on parasta pysyä poissa kursoreista, jos se on mahdollista. Kohdistimet kärsivät paitsi nopeusongelmista, mikä sinänsä voi olla ongelma monissa operaatioissa, mutta ne voivat myös saada toimintasi estämään muita toimintoja paljon kauemmin kuin on tarpeen. Tämä vähentää huomattavasti järjestelmän samanaikaisuutta.
Et kuitenkaan aina voi välttää kohdistimien käyttöä, ja kun noihin aikoihin tulee, voit ehkä päästä eroon kohdistimen aiheuttamista suorituskykyongelmista tekemällä kohdistimet sen sijaan temp-taulukkoa vastaan. Otetaan esimerkiksi kohdistin, joka kulkee taulukon läpi ja päivittää pari saraketta joidenkin vertailutulosten perusteella. Sen sijaan, että tekisit vertailun live-taulukkoon, voit ehkä laittaa nämä tiedot temp-taulukkoon ja tehdä vertailun sen sijaan. Sitten sinulla on yksi PÄIVITTÄÄ lausunto live-pöytää vastaan, joka on paljon pienempi ja pitää lukot vain lyhyen aikaa.
Tämän tyyppisten tietomuutosten leikkaaminen voi lisätä samanaikaisuutta huomattavasti. Lopuksi sanon, että sinun ei tarvitse koskaan käyttää kohdistinta. Siellä on melkein aina sarjapohjainen ratkaisu; sinun täytyy oppia näkemään se.
9. Älä pese näkymiä
Näkymät voivat olla käteviä, mutta sinun on oltava varovainen niitä käytettäessä. Näkymät voivat auttaa peittämään suuria kyselyjä käyttäjiltä ja standardoimaan tiedonsiirron, mutta voit helposti löytää itsesi tilanteesta, jossa sinulla on näkymiä, jotka kutsuvat näkymiä, jotka kutsuvat näkymiä, jotka kutsuvat näkymiä. Tätä kutsutaan pesimä näkymät, ja se voi aiheuttaa vakavia suorituskykyongelmia, erityisesti kahdella tavalla:
- Ensinnäkin, sinulla on todennäköisesti paljon enemmän tietoja palaamassa kuin tarvitset.
- Toiseksi kyselyn optimoija luopuu ja palauttaa virheellisen kyselysuunnitelman.
Minulla oli kerran asiakas, joka rakasti sisäkkäisiä näkymiä. Asiakkaalla oli yksi näkymä, jota se käytti melkein kaikkeen, koska sillä oli kaksi tärkeää liittymistä. Ongelmana oli, että näkymä palautti sarakkeen, jossa oli 2 Mt asiakirjoja. Jotkut asiakirjoista olivat vieläkin suurempia. Asiakas työnsi vähintään 2 Mt verkon yli jokaista riviä kohden lähes jokaisessa suorittamassaan kyselyssä. Luonnollisesti kyselyn suorituskyky oli kauhistuttavaa.
Ja yksikään kyselyistä ei tosiasiassa käyttänyt kyseistä saraketta! Tietysti sarake haudattiin seitsemän näkymää syvälle, joten jopa sen löytäminen oli vaikeaa. Kun poistin asiakirjasarakkeen näkymästä, suurimman kyselyn aika kesti 2,5 tunnista 10 minuuttiin. Kun löysin lopulta sisäkkäiset näkymät, joissa oli useita tarpeettomia liitoksia ja sarakkeita, ja kirjoitin tavallisen kyselyn, saman kyselyn aika putosi alasekunteihin.
