Jump to content
php.lv forumi

mysql veiktspēja


mysql_query
 Share

Recommended Posts

  • 2 weeks later...
  • Replies 34
  • Created
  • Last Reply

Top Posters In This Topic

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

Par šo tēmu ir laba grāmata High Performance MySQL un arī citas.

No ātrdarbības viedokļa 500 lauki varētu būt ātri, bet varētu arī nebūt. Vēl jau viss atkarīgs no storage engine un row struktūras (dynamic/fixed), blokiem, utt.

Praksē liela problēma varētu būt, ja dati uzaug un vajag pievienot vēl kādu lauku nepārtraucot sistēmas darbību.

Link to comment
Share on other sites

Praksē liela problēma varētu būt, ja dati uzaug un vajag pievienot vēl kādu lauku nepārtraucot sistēmas darbību.

Ja ir pietiekami jauna MySQL versija (sākot no 5.6.x) salīdzinoši daudzas operācijas notiek "onlainā" un kas it īpaši (reizēm) bez vecās tabulas pārkopēšanas:

 

https://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html#innodb-online-ddl-summary-grid

Link to comment
Share on other sites

Praktiski tas notiek tā, ka fonā tiek izveidota jauna temp tabula un tad noswapota ar shēmas tabulu. Kas, protams, priecē. Bet ja tā tabula ir ar 500 laukiem un miljoniem ierakstu, tas var būt diezgan dārgs pasākums kaut vai tādēļ, ka fonā diezgan liels process notiksies un vēl jautājums, vai un kā to var apturēt, ja nepieciešams, utt. Ar relāciju normālformu tomēr tas ir tikai viens jauns ieraksts vienā no tabulām.

 

Tas viss jāskatās no arhitektūras viedokļa, protams. Tāda viennozīmīga atbilde te nav, bet būtu labi saprast argumentus par labu vienam vai otram risinājumam. Arguments "a man tā patika" arī ir labs arguments, tāpat kā "man tā gudri mācīja visgudrākajos kursos". Tālāk jau tā ir projekta vadītāja vai klienta problēma, kam viņš uzticējis to sistēmu būvēt. :) Priekš sevis var vispār taisīt, kā labpatīk.

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


×
×
  • Create New...