eregi Posted February 27, 2008 Report Share Posted February 27, 2008 Tā lasīju par lielo tabulu struktūru, un nolēmu, ka vēlētos uzzināt kaut ko vairāk par to lauku indeksāciju. Kas tas ir? Vai to vaig pielietot tikkai tam laukam pēc, kura meklēs, piem ja tabula būs | Id | Uid | kaut kas | un, ja es tik vēlēšos atlasīt pēc Uid, tad vajag indeksēt to Uid? bet atkal, ja tabula | Id | Uid | kaut kas | un vajag atlasīt pēc Id, tad indeksēšu pēc id? Var vairākus rowus indeksēt? Kā tas fiziski notiek? Link to comment Share on other sites More sharing options...
Aleksejs Posted February 27, 2008 Report Share Posted February 27, 2008 Garš stāsts :) http://en.wikipedia.org/wiki/Index_%28database%29 http://hackmysql.com/case1 (ja mysql interesē) Principā... Tūlīt atnāks Gints Plivna un visu izstāstīs :D Link to comment Share on other sites More sharing options...
Grey_Wolf Posted February 28, 2008 Report Share Posted February 28, 2008 1. Jaa indeksaciju jaizmanto tikai tiemlaukiem peec kuriem notiks meklesana .... Un arii tad ja Rowa ir vienadi ieraksti --> teiksim ja seciba buus 1;2;3;4.. tad no Indeksa liela jega nebuus ... bet ja buus 1;2;3;1;1;3;3;2;2; tb ieraksti atkartosies tad Indexa tie tiks sakartoti --> 1;1;1;2;2;2;3;3;3 ... un meklejot tiks izmantots tikai vajadzigas rindas ... parejas ignorejot ... --> taatad saja gadijuma tiks parbauditas tikai max 3 rindinjas nevis visaas .... ### indekssa izskatiisies apmeram sadi Uid | Id 1-1 1-4 1-5 2-2 2-8 2-9 3-3 3-6 3-7 -- tatad DB peec panjems tikai toss Id kuri buus nepieciesami ..... un taalak jau straadas ar tiem... ---- 2. ID parasti ir Primary_KEY kas pats par sevi Jau ir indekss.... --> taatad nevajag (Un nemaz nevar) vinju velreiz indekseet... ---- 3. jaa Indekset var tik Rowus cik ir nepieciesamss... ------ Vispar ar tiem indeksiem ir jauzmanaas.... Nevajag arii paraak aizrauties --> var panakt preteju Efektu Atlasisanas atruma samazinasanos ... jo tiri fiziski tie ir Atseviskji ieraksti DB .. Indekss tabulaa ... un ja vinja buus liela tad.... Link to comment Share on other sites More sharing options...
andrisp Posted February 28, 2008 Report Share Posted February 28, 2008 Un arii tad ja Rowa ir vienadi ieraksti --> teiksim ja seciba buus 1;2;3;4..tad no Indeksa liela jega nebuus ... Man liekas, ka tā nav gan. Nevelti PRIMARY KEY arī tiek indeksēts. Link to comment Share on other sites More sharing options...
Aleksejs Posted February 28, 2008 Report Share Posted February 28, 2008 (edited) īsumā: jāindeksē tie lauki, kas figurē labajā pusē atslēgas vārdam WHERE. Tātad tie, pēc kuriem atlasa un pēc kuriem kārto. Ja kārto, piemēram: ORDER BY user_id, last_time tad ir jābūt tādam indeksam, kurā ir abi šie lauki un šādā secībā. Vismaz MySQL. Edited February 28, 2008 by Aleksejs Link to comment Share on other sites More sharing options...
andrisp Posted February 28, 2008 Report Share Posted February 28, 2008 Un arī tos laukus, kas tiek izmantoti tabulu joinošanai, vajag indeksēt. Protams, ne visus un ne vienmēr. Link to comment Share on other sites More sharing options...
Grey_Wolf Posted February 28, 2008 Report Share Posted February 28, 2008 andrisp --> primary key indekss ir mazliet savadaaks .... tb.. populari varetu teikt ka tam tiek noradiits no kura Baita sakas pats lauks(ieraksts..) parejiem indeksiem jau tiek izmantots mazlitinj savadaks mehanisms... --- Aleksejs --> parasti tos laukus peec kuiem karto ipashi netcensas indekseet.... nav parak lielas jeegas... , jo kartosanas nosacijumi tachu mainaas (kautvai virziens.... ) + diezavi kaads buus tik traks ka centiisies izvadiit vairak par paris K ierakstu vienlaicigi --> sekojoshi pazuud jega no indeksacijas (ieguvums ir parak nieciigs, salidzinajuma ar Resursu paterinju...) P.S. par laukiem kurus izmanto JOIN ... pats par sevi saprotams, jo primaaraa atlase tachu notiek peec tiem .... Varetu pat teikt, ka tos vajadzetu indekseet pirmaam kartam... Link to comment Share on other sites More sharing options...
Aleksejs Posted February 28, 2008 Report Share Posted February 28, 2008 Grey_Wolf - pēc pieredzes zinu, ka biežāk lietoto ORDER BY kombināciju (un manā gadījumā to nebija tik daudz, nu iedomājies kaut vai šādu forumu - te jau nav daudz to kārtošanas kombināciju) pareiza noindeksēšana deva ievērojamu ieguvumu. Parasti daru tā, ka padarbinu kādu laiku (atkarībā no sistēmas "kāds laiks" ir jēdziens sākot ar dažām minūtēm un beidzot ar nedēļām) mysqlu ar parametriem --log-slow-queries un --log-queries-not-using-indexes un tad skatos, kuri pieprasījumi ir tie, kas rada problēmas. Protams, pārlieka indeksēšana atsaucas uz ievietošanas ātrumu. Taču, daudzās tabulās ir novērojama ievērojama ievietošanas/nolasīšanas pieprasījumu asimetrija, kur lielākoties dati tiek nolasīti, tādēļ, iespējams, ka ir attaisnojams indeksēt vairāk un palielināt ievietošanas laikus. P.S. Šo vajadzētu pārvietot uz "PHP un datubāzes" sadaļu Link to comment Share on other sites More sharing options...
Grey_Wolf Posted February 28, 2008 Report Share Posted February 28, 2008 Aleksejs --> Pilniba piekritu taja zinjaa ka ir Japarbauda Indexa liederiiba..... Kaa jau mineji jaskataas arii uz to cik daudz buus INSERTI ... Teiksim users_online tabulai nepareiza indeksacija radiis situaciju ka tabula saaks ieverojami bremzeet... (parasti Inserti/ Deleti gandriiz tikpat daudz cik Select....) Link to comment Share on other sites More sharing options...
bubu Posted February 28, 2008 Report Share Posted February 28, 2008 parasti tos laukus peec kuiem karto ipashi netcensas indekseet.... nav parak lielas jeegas... , jo kartosanas nosacijumi tachu mainaas (kautvai virziens.... ) Šī nu gan nav tiesa. Tādus laukus ir ļoti liela jēga indeksēt. Jo kā gan MySQL's sakārtos šos ierakstus (nav svarīgi kādā secībā)? Viņam tie lauki būs jāsalīdzinina savā starpā, jāmeklē lielākais/mazākais. Un tieši šis lietas nodrošina indekss - ka lauka vērtību attiecībā pret citu ierakstu lauku vērtībām var salīdzināt ļoti ātri ( O(logN) - ja indekss ir balstīts uz kokiem - atškirībā no O(N) pilnas pārlases gadījumā). Link to comment Share on other sites More sharing options...
marrtins Posted February 28, 2008 Report Share Posted February 28, 2008 ORDER BY laukus ir jēga indexēt, ja 1) SELECT * FROM blabla ORDER BY index_part1, index_part2, ..., index_part<n>, kur index ir definēts katram laukam un *tieši* tādā secībā kā ORDER BY daļā (pietam, nemaisot ASC un DESC, izmantot funkcijas). (portams, var indexēt ne-pēc visiem ORDER BY izmantotiem laukiem, bet, teiksim, dažiem pirmajiem) 2) SELECT index_part1, ..., index_part<n> FROM blabla ORDER BY index_part<n+1>, ..., - index uz laukiem index_part1, index_part2 (tieši tādā secībā) Link to comment Share on other sites More sharing options...
eregi Posted February 28, 2008 Author Report Share Posted February 28, 2008 Kā tad man indeksēt to rowu? un kā Aleksej Tu palaid --log-slow-queries un --log-queries-not-using-indexes? Startējot mysql? Link to comment Share on other sites More sharing options...
Kristabs Posted February 28, 2008 Report Share Posted February 28, 2008 Piemēram, ieraksti my.cnf šos un restartē mysql. Link to comment Share on other sites More sharing options...
Gints Plivna Posted February 28, 2008 Report Share Posted February 28, 2008 Principā... Tūlīt atnāks Gints Plivna un visu izstāstīs :D Khekhe esmu kļuvis populārs :D Principā veidojot indeksus ir jāatceras dažas pamatlietas: 1) indeksi vienmēr dos papildus noslodzi veicot datu izmaiņas (insert, update, delete, merge) tabulā (nu protams, ja maina tās kolonas, kas ir indeksētas); 2) indeksi var palīdzēt datu atlases vaicājumos (select), var nepalīdzēt un var kaitēt. 3) ir indeksi bez kuriem vienkārši nevar iztikt un tas, ka tie sabremzē pasākumu, ir mazāks ļaunums, nekā tad ja to nebūtu. OK tagad pēc kārtas par uzskaitīto: 1) es ceru, ka šis punkts ir saprotams, jo parasti dbvs uztur indeksus automātiski un attiecīgi katrai rindas vērtības izmaiņai ir jādzēš vecā vērtība indeksā un jāieliek jauna, attiecīgi, ja indeksu ir daudz, tad pamainot vienu rindu ar vairākām vērtīobām tabulā ir tā jāieraksta vienā vietā tabulā un vēl jāizmaina N indeksi. 2) kad indeksi palīdz selectos? Vispārīgā gadījumā tad, kad tiek atlasīts neliels ierakstu skaits salīdzinot ar kopējo ierakstu skaitu tabulā. Neliels ir stiepjams jēdziens, un ja godīgi, tad piemēram Oraclē vispār to procentos no kopējā ierakstu skaita izteikt vienkārši nevar, bet nu ideja jādomā skaidra. Kad selectos indeksi nepalīdz, bet arī nekaitē? Tad, ja visas tabulas skanēšana (FULL SCAN) ir efektīvāka metode nekā lasīšana izmantojot pieeju cikls indekss tabula cikla beigas un attiecīgā DBVS (un programmētājs) to saprot un full scan arī lieto. Kad indeksi selectos kaitē? Tiklīdz kā FULL SCANS būtu bijis efektīvāks nekā iepriekšējā punktā minētā pieeja, bet vai nu DBVS pati maldīgi ir izdomājusi, ka jālieto indekss, vai arī programmētājs ir salasījies stāstus, ka vienmēr jālieto indeksi un piespiež DBVS tos izmantot vienmēr. 3) indeksi bez kuriem nevar nekādi iztikt ir primāro un unikālo atslēgu indeksi. Tie parasti tiek izveidoti automātiski, tiklīdz mēs uzliekam attiecīgos ierobežojumus (constraint), jo citādi vienkārši DBVS pie katra jauna ieraksta izveides vai esošā koriģēšanas būtu jāskrien cauri visai tabulai un jāmeklē vai tik tāda vērtība jau nav priekšā. Ja mums ir indekss, tad to var noskaidrot daudz ātrāk izmantojot indeksu. Šīs bija lietas kas -+ ir kopīgas visām DBVS. MySQL specifiskās lietas es nevaru izstāstīt, jo to vienkārši nepārzinu. Te lūk ir jauka prezentācija par MySQL ātrdarbību tai skaitā indeksu (ne)izmantošanu. Kā redzams MySQL ir spējīgs kā minimums izmantot indeksu arī kā šaurāku tabulu (ja selectā ir tikai 2 kolonas, tad nav jānolasa visa tabula ar Ntajām kolonām, bet pietiek tikai ar indexu). Gints Plivna http://datubazes.wordpress.com Link to comment Share on other sites More sharing options...
Gints Plivna Posted February 28, 2008 Report Share Posted February 28, 2008 ā un vēl, tā kā MySQLā izskatās, ka ir tikai un vienīgi Nested loops joinu mehānisms, t.i., Ciklā katram ierakstam ārējā tabulā atrodam indeksā norādes uz iekšējās tabulas rindām braucam uz konkrētām iekšējās tabulas rindām pēc indexa Attiecīgi, ja nav indexa uz FK kolonas, tad sanāk tik full skani pa iekšējo tabulu, cik atlasa ārējās tabulas rindas, t.i, Ciklā katram ierakstam ārējā tabulā Full skanā meklējam iekšējās tabulas rindas Citās DBVS to realizē ar MERGE JOIN vai HASH JOIN palīdzību, kam indeksus nevajag, bet kas nolasa 1reiz ārējo tabulu, tad 1reiz iekšējo tabulu un tad veic kombinēšanu. Par šito neesmu 100% drošs, būs laikam man tomēr jāuzinstalē MySQL uz mājas kastes, lai varētu savus izteikumus pārbaudīt :) Gints Plivna http://datubazes.wordpress.com Link to comment Share on other sites More sharing options...
Recommended Posts