Jump to content
php.lv forumi

mysql veiktspēja


mysql_query

Recommended Posts

  • Replies 34
  • Created
  • Last Reply

Top Posters In This Topic

Ja objektu raksturo 500 skalari propertiji tad es arī taisītu 500 kolonas

 

Iedomu pasaulē - jā. Reālā dzīvē nez vai atradīsies kas tāds, kam ir 500 tik ļoti dažādi propertiji kurus nevar normalizēt/grupēt :) Kā matemātikas uzdevumos, kad Jānītim ir divas tonnas ābolu, bet ilzītei tikai 200 kg

Link to comment
Share on other sites

^ Tā arī rodas tādi over-engineringi kā leaf cms. Ja kaut kas ir pārāk vienkārši obligāti vajag uztaisīt sarežģītāk, lai tik kolēģi nepadomā, ka necert zivi

 

Tu kaut kādu bezsakaru runā te. Labāk ir, kad phpdoc modeļa propertiji neielien vertikāli ekrānā? Kurš vispār tādu kluci var uzturēt? 

Te ir ~80 propertiji (nav kolonnas visas, bet dažiem gribētos pat vairāk), un jau ir psc kkam izsekot līdzi, pat ar IDEi.

 

img.2015.08.27.y7i0Vu.png

Link to comment
Share on other sites

Nopērc lielāku monitoru.

Es jau iepriekšējā lapā izskaidroju kāpēc ir bezjēdzīgi dalīt pa tabulā, tikai tāpēc, ka kādam šķiet, ka lauku par daudz. Perfomance un programmēšanas ērtums.

Programmējot tu to dari, lai tas darbotos ātri un nerītu mežonīgi daudz servera resursu, nevis lai apmierinātu savus koda fetišus

Link to comment
Share on other sites

Programmējot tu to dari, lai tas darbotos ātri un nerītu mežonīgi daudz servera resursu, nevis lai apmierinātu savus koda fetišus

 

Nu te sanāk forša pretruna. Milzīgi kvēriji, daudz rezultāti tiek atgriezti, milzīgi masīvi. Selektīvi selekti, tu saki? Aha, kuram gan negribas uzskaitīt 30 kolonnas ar roku, un tad, kad kaut kas mainās, tad labot 20 vietās :)

 

99.9% gadījumu kodē, lai kods būtu viegli saprotams, uzturams, Nevienam nav vajadzīgi super duper  mega ģeniāli algoritmi, kurus neviens nesaprot, bet redz darbojas par 10ms ātrāk. Dzelži ir lēti...

Link to comment
Share on other sites

Šis vienkāršums un mežonīgā perfomance

 

SELECT id FROM mega_tabula t WHERE (t.field1='v1' AND t.field2='v2') OR t.field3='v3' AND t.field4 LIKE '%v1%' ORDER BY t.field22 ASC, t.field150 DESC, t.field500 ASC;

 

Pret šo neglītumu un neidomājamu bremzi

 

SELECT id FROM tabula1

LEFT JOIN tabula2 ON tabula1.id=tabula2.id

LEFT JOIN tabula3 ON tabula1.id=tabula3.id

LEFT JOIN tabula4 ON tabula1.id=tabula4.id

LEFT JOIN tabula5 ON tabula1.id=tabula5.id

LEFT JOIN tabula150 ON tabula1.id=tabula5.id

LEFT JOIN tabula500 ON tabula1.id=tabula5.id

WHERE (t1.field1='v1' AND t2.field2='v2') OR t3.field3='v3' AND t4.field4 LIKE '%v1%'

ORDER BY t5.field22 ASC, t150.field150 DESC, t500.field500 ASC;

 

Kurš labāks?

Link to comment
Share on other sites

Tie visi izdomātie kolonu limiti ir smieklīgi. Ja man tiešām vajag 500 kolonnas es tās likšu vienā tabulā. Nevis speciāli domāšu dalīšu pa tabulām, tikai lai ievērotu izdomātu limitu.

Ja būs vajadzība filtrēt pēc 5 laukiem, kur katrs ir savā tabulā, tad man nāksies tās visas tabulas JOINot un tad filtrēt. Ja vēl vajadzēs pēc tām pašām kolonnām ORDER BY, tad tas query būs ļoti, ļoti lēns.

Programmētāju ietiepība ar reizēm ir smieklīga (reizēm gan nāk dusmas u.c. izpausmes).

 

 

Bet nu atbilde par to, kas ir labāks un ātrāks nav viennozīmīga, kaut vai dēļ šādiem jautājumiem:

- Vai atlasīšanas kveriji ir jāveic pēc visiem 500 laukiem? Ja jā un ja tev ir 500 kolonnu tabula, tad arī no tādas selectējot pēc kaut kādiem 5 laukiem kverijs būs "lēns", jo lai gan tagad ir nedaudz labāka situācija ( https://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html) tad principā vai nu tev jātaisa tabulai 500 indeksi (pie kam innodb var būt tikai 64) vai jāizvēlas uz kuriem likt uz kuriem nē, bet galugalā pasākums nekāds ideāls nav.

- Vai ieraksta visas vērtības/kolonnas vienmēr satur vērtību? Ja nē, tad atkarībā no tā kāds % ir aizpildījumam var tikt zaudēts diezgan daudz diskvietas.

 

 

Tāpēc jau arī eksistē dažādi NoSQL, kā arī veidi tradicionālajās RDBMS ( piem https://mariadb.com/kb/en/mariadb/column_json/) kā optimālāk iebakstīt objektam 500 vērtības.

Link to comment
Share on other sites

Šis vienkāršums un mežonīgā perfomance

 

SELECT id FROM mega_tabula t WHERE (t.field1='v1' AND t.field2='v2') OR t.field3='v3' AND t.field4 LIKE '%v1%' ORDER BY t.field22 ASC, t.field150 DESC, t.field500 ASC;

 

Pret šo neglītumu un neidomājamu bremzi

 

SELECT id FROM tabula1

LEFT JOIN tabula2 ON tabula1.id=tabula2.id

LEFT JOIN tabula3 ON tabula1.id=tabula3.id

LEFT JOIN tabula4 ON tabula1.id=tabula4.id

LEFT JOIN tabula5 ON tabula1.id=tabula5.id

LEFT JOIN tabula150 ON tabula1.id=tabula5.id

LEFT JOIN tabula500 ON tabula1.id=tabula5.id

WHERE (t1.field1='v1' AND t2.field2='v2') OR t3.field3='v3' AND t4.field4 LIKE '%v1%'

ORDER BY t5.field22 ASC, t150.field150 DESC, t500.field500 ASC;

 

Kurš labāks?

Šis ir nekorekts salīdzinājums, jo neviens (parasti) tā netaisa.

 

Tabula parasti ir tikai viena (nevis tabula1, tabula2, tabula500) un satur 3 laukus:

objekta_id | propertija_nosaukums | propertija_vertiba

 

Un tad selecteejot WHERE propertija_nosaukums = 'kautkas' AND propertija_vertiba = 'kautkaada' var atlasiit visus nepieciešamo objektu_id (kuriem tad piejono galveno tabulu(as) - attiecīgi tikai 1 JOINs) ..

Link to comment
Share on other sites

Protams, tāpēc jau ir svarīgi ko, kā un kas ar tiem 500 laukiem jādara.

 

 

Mans komentārs bija tikai par to, ka salīdzinājums nav visai korekts un kverijam:

SELECT id FROM mega_tabula t WHERE (t.field1='v1' AND t.field2='v2') OR t.field3='v3' AND t.field4 LIKE '%v1%' ORDER BY t.field22 ASC, t.field150 DESC,  

nekādus sakarīgus indeksus ņemot verā MySQL īpatnības uzlikt nevar (ja tomēr, tad gribu noteikti redzēt (nopietni!) :) ) un nekāda "mežonīga" performance nebūs  - protams, ja ieraksti būs zem < ~1mio (nu vai tabulas izmērs salien servera ramā (filecache)) un mysql instance nebūs kaut kāds diloņa slimnieks (nemaz nerunājot, ja kverijs iekešojas), tad protams izpildīsies arī samērojamā laikā (lasi, pietiekami ātri) jebšu tas saucas 'full table scan'.

Link to comment
Share on other sites

Protams, ierobežojumi ir abos gadījumos.

Es arī neesmu saskāries ar 500 laukiem tabulā, bet ticu, ka īpašos gadījumos ir vajadzība, tāpēc arī uzsvēru, ka nevajag balstīties uz iedomātie ierobežojumiem.

 

Kāpēc selektējot pēc vairāk par 5 laukiem query būs lēnaks? Slinkums tagad lasīt to linku

Link to comment
Share on other sites

Īsumā - MySQL jēdzīgi māk izmantot tikai vienu tabulas indeksu (eksistē tur protams tagad visādas index-merge optimizācijas) bet in general ideja ir tāda - proti ja WHERE kolonna ir vienā indeksā bet ORDER vai GROUP kolonna ir citā indeksā tad ir "ziepes", atkarībā no mysql optimizera sajūtām var tikt izmantots tikai tas indekss kas ir WHERE nosacijumā un rezultāti kārtoti "fiziski" jebšu otrādi - mysql var izdomāt ka sasortēt tabulu ar miljons ierakstiem ir ātrāk un tad skriet tai cauri "manuāli" (row-by-row) pārbaudot katru vērtību un atlasīt tikai konkrētus ierakstus.
 

Savukārt kombinētos indeksus lielam lauku skaitam ir sarežģīti uzlikt - piemēram, ja ir indeks uz (kolonna1,kollona2, kollona3) tad kverijs WHERE kolonna1 = 'lala', kolonna2='blabla', ODER BY kolonna3 ir OK, bet kverijs WHERE kolonna1 = 'lala', ODER BY kolonna3 vairs nē (proti indekss tiks izmantots, taču tikai atlasei, bet ne kārtošanai), tāpat WHERE kolonna2='blabla', ODER BY kolonna3 (šeit vispār nē) utt... 

Protams, ja kveriji ir vienmēr fiksēti (noteikti (un ne pārāk daudz variacijās) WHERE/ORDER nosacījumi) tad ir savādāk, bet praksē parasti nācies sastapties ar to ka tos WHERE/ORDER ik pa laikam maina vai arī nepieciešams tik dinamiski kārtot, ka puse no sākotnēji uzliktajiem tabulas indeksiem ir vai nu lieki vai pārklāj citus vai neizmantojas vispār.

 

 

Tā kā bundža ar daudz tārpiem ..

Link to comment
Share on other sites

Uz katru lauku indeksus neliks. Indeksu pieskaņos vajadzīgajā atskaitēm

 

Un kā ir ar šādu situāciju, tas var radīt kaut kādas problēmas?

indekss1 (lauks1, lauks2, lauks3)

indekss2 (lauks2, lauks3, lauks4)

 

Tu dažas ļoti labas nianses izstāstīji

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...