marrtins

Mhm, lai būiu pa smuko, jālaiž uz siltajām zemēm, pludmalē, kedas pret sauli...

Fellony ms mīlētājs :) Lai būtu pa smuko, varbūt vispār ģenerēt outputu ar kādu xml lib?

Nu tā arī var, protams. Vēl var paspēlēties ar partiotioning: http://www.tritux.com/blog/2010/11/19/partitioning-mysql-database-with-high-load-solutions/11/1 Pats gan neesmu šo izmantojis un nez cik tas labi darbojas.

Kur noselektot? Ar ko noselektot? Kur izechot? Troll on!

Nekas sikk tur nav. Tā mēdz darīt. Tūkstotis vai vairāk tabulu ;)

Vajadzētu sākt ar to, ka noskaidrot kādēļ vēstules tiek uzskatītas par spam/junk. Man šķiet pie tām mēstulēm jābūt arī aprakstam, kādēļ tās tiek uzskatītas par spamiem. Varbūt headeros jāpaskatās.

Ja jau dati nemainās, vēl ir variants: sadala pa tabulām, katrā pa 50`000 vai 100`000 ierakstiem :)

Varbūt kaut kādos hipsterjaunākajā css var (bet varbūt arī nevar). Nāksies vien taisīt parent child child child. Uzliec tam main divam kādu klasi/id un tad div.klase ul li.active { border: 1px solid red; }

InnoDB gan dati gan index tiek mesti poolā. Laigan, protams, index uz integer kaut vai uz miljonu ir pāris mb un vēl pāris mb overhead datustruktūrām. Domāju, ka nevajadzētu būt tik traki... to bufferpoolu jau arī kādreiz atbrīvo :) Gan jau tur ir algoritmi, kas interesantākās lietiņas "patur prātā", bet drazu izmet. Nu tad pieseivo statiskas HTML lapiņas katram atvērumam. Pārģenerē tikai pirmo reizi un jaunāko lapu, kamēr piepildās. Nu tas būtu tizli - papildus dati (piekam, visnotaļ nevajadzīgi) kā arī ja kas pamainās, tad tādai DB kautko pielikt/noņemt būs tāāds čžžž.

Tas 0.3s ar join ir uz reāliem datiem? Izklausās OK. Rēķini, ka tiem vajadzētu vēl lielāku poolu. Nokešo to count, vai, ja nepieciešams realtiem - notrigerē ;) Kā būtu, ja offsets iet pāri pa pusei, tad sortētu pēc ID desc un attiecīgi būtu offsets (count - īstais_offsets - limit), tb, LIMIT count-50000-10,10 Pēc tam ar php sasortē pretēji. Vienīgais, nez cik ātri tas PHP sasortēs...

Uzliec innodb_buffer_pool_size uz kādi 512MB un palaid kveriju divreiz (warm up cache) :P

Ja where nosacījumi nemainās, paņem iemet visus ID sanumurētus kādā cache un tālāk jau tikai atlasi vajadzīgos ID no cache un tālāk rindas paprasi mysql.

Šis nav tas gadījums.

Ne vienmēr un ne tik viennozīmīgi. Vnk ja tas mysql analizators izdomās, ka ātrāk būs fullscan, kā index access un tad datu access, tad indexus arī var neizmantot. Gadās, protams, ka kļūdās. codez, cik liels tev id buffer pools (show status like 'innodb%')? Izklausās pārāk maza atšķirība.

Pamēģinājo to kveriju no stackoverflow ar join uz tās pašas tabulas?

Index tiek izmantot atlaisei/kārtošanai. Pēc tam mysql iterē līdz vajadzīgajiem ierakstiem. Jo vairāk kolonnas, jo lēnāk. Ja tu testēji tikai ar vienu id kolonnu, tad varētu arī būt ātri. Ja pietiekams buffer pool, tad bik ātrāk varētu būt atlasīt tikai id (par cik tas ir indexā un nav jāaiztiek dati) un sajoinot vēlreiz ar to pašu tabulu un ar vajadzīgajiem datiem, vai kaut vai *.

Man šķiet, ka tas bija tāpēc, ka "skrollēšanai" ar LIMIT tas index nemaz netiek izmantots. Kāpēc nē - nezinu. Ā, vēl pamēģini tikai ar "select testdb.id" nevis *.

Vot vot >:( Laikam būs jāsāk darīt kas lietderīgāks, piemēram, Quake?

Un man likās tas speciāli atslēgts, lai nespamotu (nevajadzīgas quotes) un uzlabotu rakstītā kvalitāti (5x pārlasīt, jo edit nestrādā) :D

Tev nostrādās tikai pirmie no rullēm RewriteRule ^([^/]*)/$ /?lang=$1 [NC,OR] un RewriteRule ^([^/]*)/([^/]*)/$ /?lang=$1&pg=$2 [NC,OR] Pārējie taču ir identiski.

Nu vismaz kādus screenshotus uzģenerētajiem vizuālajiem elementiem....

Tekstūru un terrainu ģenerēšana taču nav nekas jauns. Bet vienalga izklausās interesanti - dod ievērtēt :)

Kau kas tāds? http://xoxco.com/projects/code/tagsinput/ Vēl tik piestilot un būs gerai.

suicidālo commitu?

echo date('d.m.Y', strtotime('10.11.2012 + 60 days'));