ne php - mysql indeksācija.

[eregi]

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?

[Aleksejs]

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

[Grey_Wolf]

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....

[andrisp]

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.

[Aleksejs]

ī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

[andrisp]

Un arī tos laukus, kas tiek izmantoti tabulu joinošanai, vajag indeksēt. Protams, ne visus un ne vienmēr.

[Grey_Wolf]

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...

[Aleksejs]

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

[Grey_Wolf]

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....)

[bubu]

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ā).

[marrtins]

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ā)

[eregi]

Kā tad man indeksēt to rowu?

 

un kā Aleksej Tu palaid --log-slow-queries un --log-queries-not-using-indexes? Startējot mysql?

[Kristabs]

Piemēram, ieraksti my.cnf šos un restartē mysql.

[Gints Plivna]

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

[Gints Plivna]

ā 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