SQL izstrādātāji katrā platformā cīnās, šķietami iestrēdzis DARĪT KAMĒR cilpa, kas liek viņiem atkārtot tās pašas kļūdas atkal un atkal. Tas ir tāpēc, ka datu bāzes lauks joprojām ir salīdzinoši nenobriedis. Protams, pārdevēji veic dažus soļus, taču viņi turpina cīnīties ar lielākiem jautājumiem. Vienlaicīgums, resursu pārvaldība, kosmosa pārvaldība un ātrums joprojām traucē SQL izstrādātājiem neatkarīgi no tā, vai viņi kodē SQL Server, Oracle, DB2, Sybase, MySQL vai jebkuru citu relāciju platformu.
Daļa no problēmas ir tā, ka nav burvju lodes, un gandrīz katrai paraugpraksei es jums varu parādīt vismaz vienu izņēmumu. Parasti izstrādātājs atrod savas iecienītās metodes - lai gan parasti tās neietver nekādus veiktspējas vai vienlaicīguma konstruktus - un neuztraucas izpētīt citas iespējas. Varbūt tas ir izglītības trūkuma simptoms, vai arī izstrādātāji ir pārāk tuvu procesam, lai atpazītu, kad dara kaut ko nepareizi. Varbūt vaicājums darbojas vietējā testa datu kopā, bet ražošanas sistēmā tas neizdodas.
Es nedomāju, ka SQL izstrādātāji kļūs par administratoriem, taču, rakstot kodu, viņiem jāņem vērā ražošanas problēmas. Ja sākotnējās izstrādes laikā viņi to nedarīs, DBA vienkārši liks viņiem atgriezties un darīt to vēlāk - un lietotāji pagaidām cieš.
Ir iemesls, kāpēc mēs sakām, ka datu bāzes pielāgošana ir gan māksla, gan zinātne. Tas ir tāpēc, ka ir ļoti maz stingru un ātru noteikumu, kas tiek piemēroti visā pasaulē. Problēmas, kuras esat atrisinājis vienā sistēmā, nav problēmas citā un otrādi. Kad tiek meklēti jautājumi, nav pareizas atbildes, taču tas nenozīmē, ka jums vajadzētu atteikties.
Ir daži labi principi, kurus varat ievērot un kuriem vajadzētu dot rezultātus vienā vai otrā kombinācijā. Es tos iekopēju SQL lietojumu un aizliegumu sarakstā, kurus bieži aizmirst vai kurus ir grūti pamanīt. Šīm metodēm vajadzētu dot jums nedaudz lielāku ieskatu jūsu DBA prātos, kā arī spēju sākt domāt par procesiem uz ražošanu orientētā veidā.
1. Nelietojiet ATJAUNINĀT tā vietā LIETA
Šis jautājums ir ļoti izplatīts, un, lai arī to nav grūti pamanīt, daudzi izstrādātāji to bieži ignorē, jo izmanto ATJAUNINĀT ir dabisks parāds, kas šķiet loģisks.
Piemēram, izmantojiet šo scenāriju: jūs ievietojat datus temp tabulā un jums ir nepieciešams, lai parādītu noteiktu vērtību, ja pastāv cita vērtība. Varbūt jūs pavelkat no klienta galda un vēlaties, lai ikviens, kura pasūtījumi pārsniedz 100 000 ASV dolāru, tiktu apzīmēti kā “Vēlamie”. Tādējādi jūs ievietojat datus tabulā un palaižat ATJAUNINĀT paziņojums, lai iestatītu kolonnu CustomerRank uz “Preferred” ikvienam, kura pasūtījumi pārsniedz USD 100 000. Problēma ir tā, ka ATJAUNINĀT paziņojums tiek reģistrēts, tas nozīmē, ka tam ir jāraksta divreiz par katru atsevišķu rakstīšanu tabulā. Protams, ir jāizmanto inline LIETA priekšrakstu pašā SQL vaicājumā. Katrā rindā tiek pārbaudīts pasūtījuma summas nosacījums un tiek iestatīta iezīme “Vēlamais”, pirms tā tiek ierakstīta tabulā. Veiktspējas pieaugums var būt satriecošs.
2. Nelietojiet akli atkārtoti izmantot kodu
Arī šis jautājums ir ļoti izplatīts. Ir ļoti viegli kopēt kāda cita kodu, jo jūs zināt, ka tas iegūst nepieciešamos datus. Problēma ir tā, ka diezgan bieži tas iegūst daudz vairāk datu nekā jums nepieciešams, un izstrādātāji reti apgrūtina to apgriešanu, tāpēc viņiem rodas milzīgs datu kopums. Parasti tas notiek kā papildu ārējais savienojums vai papildu nosacījums KUR klauzula. Jūs varat iegūt milzīgu veiktspējas pieaugumu, ja apgriezīsit atkārtoti izmantoto kodu atbilstoši savām precīzajām vajadzībām.
3. Izvelciet tikai nepieciešamo kolonnu skaitu
Šis jautājums ir līdzīgs 2. izdevumam, taču tas attiecas tikai uz slejām. Kodēt visus savus jautājumus ir pārāk viegli SELECT * tā vietā, lai uzskaitītu kolonnas atsevišķi. Atkal problēma ir tā, ka tā iegūst vairāk datu nekā nepieciešams. Esmu redzējis šo kļūdu desmitiem un desmitiem reižu. Izstrādātājs veic a SELECT * vaicājums pret tabulu ar 120 kolonnām un miljoniem rindu, bet beidzas, izmantojot tikai trīs līdz piecas no tām. Tajā brīdī jūs apstrādājat tik daudz datu, cik nepieciešams, ir brīnums, ka vaicājums vispār tiek atgriezts. Jūs apstrādājat ne tikai vairāk datu nekā nepieciešams, bet arī atņemat resursus citiem procesiem.
4. Nemērciet divreiz
Lūk, vēl vienu, ko esmu redzējis vairāk reižu, nekā vajadzētu: Saglabāta procedūra tiek uzrakstīta, lai izvilktu datus no tabulas ar simtiem miljonu rindu. Izstrādātājam nepieciešami klienti, kuri dzīvo Kalifornijā un kuru ienākumi pārsniedz 40 000 USD. Tāpēc viņš vaicā klientus, kuri dzīvo Kalifornijā, un rezultātus apkopo tabulā par temperatūru; tad viņš vaicā klientiem, kuru ienākumi pārsniedz 40 000 USD, un ievieto šos rezultātus citā temp tabulā. Visbeidzot, viņš pievienojas abām tabulām, lai iegūtu galaproduktu.
Vai tu mani izjoko? Tas jādara vienā vaicājumā; tā vietā jūs divreiz iegremdējat lielu tabulu. Neesi debīls: ja iespējams, vaicājiet lielas tabulas tikai vienu reizi - jūs uzzināsiet, cik daudz labāk veic jūsu procedūras.
Nedaudz atšķirīgs scenārijs ir tad, kad vairākiem procesa posmiem ir nepieciešama lielas tabulas apakškopa, kas katru reizi liek uzdot vaicājumu lielajai tabulai. Izvairieties no tā, vaicājot apakškopai un saglabājot to citur, pēc tam norādot turpmākās darbības uz mazāku datu kopu.
6. Veiciet datus pirms posma
Šī ir viena no manām iecienītākajām tēmām, jo tā ir veca tehnika, kas bieži tiek ignorēta. Ja jums ir pārskats vai procedūra (vai vēl labāk - to kopa), kas līdzīgi savienosies ar lielām tabulām, jums var būt noderīgi iepriekš sagatavot datus, pirms laika pievienojoties tabulām un saglabājot tās tabulā. Tagad pārskati var darboties pret iepriekš sagatavoto tabulu un izvairīties no liela pievienošanās.
Jūs ne vienmēr varat izmantot šo paņēmienu, taču, kad varat, jūs atradīsit, ka tas ir lielisks veids, kā ietaupīt servera resursus.
Ņemiet vērā, ka daudzi izstrādātāji pārvar šo pievienošanās problēmu, koncentrējoties uz pašu vaicājumu un ap savienojumu izveidojot tikai skatu, lai viņiem nebūtu atkal un atkal jāievada pievienošanās nosacījumi. Bet šīs pieejas problēma ir tā, ka vaicājums joprojām tiek palaists katram pārskatam, kuram tas nepieciešams. Iepriekš sagatavojot datus, savienojums tiek palaists tikai vienu reizi (teiksim, 10 minūtes pirms pārskatiem), un visi pārējie izvairās no lielās pievienošanās. Es nevaru pateikt, cik ļoti es mīlu šo tehniku; lielākajā daļā vidēs ir populāras tabulas, kas tiek pievienotas visu laiku, tāpēc nav iemesla, kāpēc tās nevarētu iepriekš iestudēt.
7. Vai izdzēst un atjaunināt partijas
Šeit ir vēl viena vienkārša tehnika, kas tiek daudz ignorēta. Liela apjoma datu dzēšana vai atjaunināšana no milzīgām tabulām var būt murgs, ja jūs to nedarāt pareizi. Problēma ir tā, ka abi šie paziņojumi tiek palaisti kā viens darījums, un, ja jums tie ir jānogalina vai ja kaut kas notiek ar sistēmu, kamēr viņi strādā, sistēmai ir jāatgriež viss darījums. Tas var aizņemt ļoti ilgu laiku. Šīs darbības var bloķēt arī citus darījumus to darbības laikā, būtībā izmantojot sistēmu.
Risinājums ir izdzēst vai atjaunināt mazākās partijās. Tas atrisina jūsu problēmu pāris veidos. Pirmkārt, ja darījums kāda iemesla dēļ tiek nogalināts, tam ir tikai neliels rindu skaits, lai atgrieztos, tāpēc datu bāze tiešsaistē atgriežas daudz ātrāk. Otrkārt, kamēr mazākās partijas apņemas darboties diskā, citas var ielīst un paveikt kādu darbu, tāpēc vienlaicīgums tiek ievērojami uzlabots.
Saskaņā ar šīm nostādnēm daudziem izstrādātājiem ir iestrēdzis, ka šīs dzēšanas un atjaunināšanas darbības jāpabeidz tajā pašā dienā. Tas ne vienmēr ir taisnība, it īpaši, ja arhivējat. Jūs varat izstiept šo darbību tik ilgi, cik jums nepieciešams, un mazākās partijas palīdz to paveikt. Ja šo intensīvo darbību veikšana var aizņemt ilgāku laiku, pavadiet papildu laiku un nemaziniet sistēmu.
8. Izmantojiet temp tabulas, lai uzlabotu kursora veiktspēju
Es ceru, ka mēs visi jau zinām, ka vislabāk ir turēties tālāk no kursoriem, ja tas vispār ir iespējams. Kursori cieš ne tikai no ātruma problēmām, kas pats par sevi var būt problēma ar daudzām darbībām, bet arī var izraisīt jūsu darbības bloķēšanu citās darbībās daudz ilgāk, nekā nepieciešams. Tas ievērojami samazina vienlaicīgumu jūsu sistēmā.
Tomēr ne vienmēr varat izvairīties no kursoru izmantošanas, un, iestājoties šiem laikiem, iespējams, varēsit izvairīties no kursora izraisītām veiktspējas problēmām, tā vietā veicot kursora darbības pret temp tabulu. Ņemiet, piemēram, kursoru, kas iziet cauri tabulai un atjaunina pāris kolonnas, pamatojoties uz dažiem salīdzināšanas rezultātiem. Tā vietā, lai veiktu salīdzināšanu ar tiešraides tabulu, jūs, iespējams, varēsit ievietot šos datus tabulas tempā un salīdzināt ar to. Tad jums ir viens ATJAUNINĀT paziņojums pret dzīvu galdu, kas ir daudz mazāks un tur slēdzenes tikai īsu laiku.
Šādu datu modifikāciju izgriešana var ievērojami palielināt vienlaicīgumu. Nobeigumā teikšu, ka gandrīz nekad nav jāizmanto kursors. Gandrīz vienmēr ir komplekts balstīts risinājums; jums jāiemācās to redzēt.
9. Nelieciet skatus
Skati var būt ērti, taču, tos lietojot, jābūt uzmanīgiem. Lai gan skati var palīdzēt aizsegt lielus lietotāju vaicājumus un standartizēt piekļuvi datiem, jūs varat viegli nonākt situācijā, kad jums ir skati, kas zvana skatus, kas zvana skatus, kas zvana skatus. To sauc ligzdojošie skati, un tas var izraisīt nopietnas veiktspējas problēmas, īpaši divos veidos:
- Pirmkārt, jums, visticamāk, būs daudz vairāk datu, nekā jums nepieciešams.
- Otrkārt, vaicājumu optimizētājs atteiksies un atgriezīs nepareizu vaicājumu plānu.
Man reiz bija klients, kurš mīlēja ligzdošanas skatus. Klientam bija viens skats, ko tas izmantoja gandrīz visam, jo tam bija divi svarīgi savienojumi. Problēma bija tā, ka skats atgrieza kolonnu, kurā bija 2 MB dokumenti. Daži dokumenti bija vēl lielāki. Klients spieda tīklā vismaz 2 MB par katru rindu gandrīz katrā izpildītajā vaicājumā. Protams, vaicājumu veiktspēja bija neveiksmīga.
Un neviens no vaicājumiem faktiski neizmantoja šo kolonnu! Protams, kolonna tika aprakta septiņu skatu dziļumā, tāpēc pat atrast to bija grūti. Kad es noņēmu dokumenta kolonnu no skata, lielākais vaicājums bija no 2,5 stundām līdz 10 minūtēm. Kad es beidzot atšķetināju ligzdotos skatus, kuriem bija vairākas nevajadzīgas pievienošanās un kolonnas, un uzrakstīju vienkāršu vaicājumu, tā paša vaicājuma laiks nokritās līdz sekundēm.
