hmnc Posted December 14, 2006 Report Share Posted December 14, 2006 bet tas jau vecajiem FreeBSD. Maijā tika likta FBSD 6.1 relīze un viss ok :) Link to comment Share on other sites More sharing options...
Roze Posted December 14, 2006 Report Share Posted December 14, 2006 bet tas jau vecajiem FreeBSD. Maijā tika likta FBSD 6.1 relīze un viss ok :) Par to jau neviens arī nestrīdas .. tomēr MySQLs ir vairāk linex native aplikācija arī enterprise supports priekš BSD kā platformas idejiski nav http://www.mysql.com/support/supportedplat...enterprise.html (tas protams nav nekāds šķērslis comunity versijai bet savi iemesli ganjauka tam ir). Proti ko gribēju ar to teikt ka labāk izvēlēties to vidi kurā konkrētais produkts tiek pastiprināti uzmanīts un lietots .. Link to comment Share on other sites More sharing options...
hmnc Posted December 14, 2006 Report Share Posted December 14, 2006 es gan šoreiz sliecos uz konfiga kļūdām + db struktūras nepārdomātību. pietam piemēram meklēt ar LIKE%% ir diezgan nu tāds tāds variants. vai nu jātaisa linkotā tabula (ja vienā laukā ir vairāki parametri, pēc kuriem var atlasīt) ar konkrētiem identifikatoriem, vai arī ja tiešām tur teksts jāmeklē tad taisi fulltext indeksēšanas tabulu, insertēšanas tabulu un ja nav nekas nenormāli steidzams tad šedūleris ar datu dublēšanu. vienkārši un saprotami un domājams daudz ātrāk Link to comment Share on other sites More sharing options...
hmnc Posted December 14, 2006 Report Share Posted December 14, 2006 pietam tas izskatās pēc iveikala. tur vēlams ir palasīties kā pareizi taisīt parametru sistēmu, jo tas tiešām nav divus pirkstus .. :) ja jau ir tik ļoti liela vēlme meklēt pēc atsevišķiem parametriem. Link to comment Share on other sites More sharing options...
Roze Posted December 14, 2006 Report Share Posted December 14, 2006 es gan šoreiz sliecos uz konfiga kļūdām + db struktūras nepārdomātību. Nu runa gāja par INSERTiem un tākā konkrētajā piemērā tabulas definicijā bija tikai viens primary index (tādējādi par struktūru kur uz vienu indeksu tiek patērēta viena laika vienība runāt nevar) tad ir jocīgi ka ir tādas problēmas (patiesībā vienalga kādi ir pārējie lauki) .. Idejiski pat FULLTEXT indeksus vajadzētu spēt gāzt iekšā ar diezgan lielu ātrumu (vismaz pārsimt sekundē). Līdz ar to vai nu paša MySQL vai arī dzelzis uz kā tas griežas ir totāli saliecies.. Link to comment Share on other sites More sharing options...
hmnc Posted December 14, 2006 Report Share Posted December 14, 2006 nu a ja tajā pašā laikā viņam iet SELECTi? aizdomīgi vispār. man uz 3k ierakstiem inserti ar 3 fulltext un 1primary indexiem taisās ~6sec. dzelzis gan 2xOpteron Link to comment Share on other sites More sharing options...
ohmygod Posted December 14, 2006 Author Report Share Posted December 14, 2006 Tie selecti, kas iet inserta laikā ir precīzi. tb name= 'name' name ir indeksēts. Piemērā nebiju iemetis... Un nē, tas nav iveikals... Tas vispaar nav nekas publisks. Uz doto mirkli ir panākts ātrums, kas mani pilnībā apmierina! pateicos. Link to comment Share on other sites More sharing options...
hmnc Posted December 15, 2006 Report Share Posted December 15, 2006 nu tas, ka viņi ir precīzi neko nenozīmē. un redz mēs īsti nevarējām arī neko tev pateikt, jo pats saki, ka piemērā nebiji iemetis, ka name ir indeksēts arī un vēl kas tik tur nē :) varchar laukus vispār indeksēt ir diezgan liels neprāts pie lieliem datu apjomiem. nezinu ko speci teiks, bet manuprāt labi joini strādā ātrāk par kkādiem %like% vai indeksiem uz varchar255 Link to comment Share on other sites More sharing options...
Grey_Wolf Posted December 15, 2006 Report Share Posted December 15, 2006 bet manuprāt labi joini strādā ātrāk par kkādiem %like% vai indeksiem uz varchar255 taa arii ir :) + varchar vispaar nav aatrs datu tips idiali ir tureet char / tabula gan iznaak krietni 'smagaaka', toties ieveerojami aatraaka... padomaa pats , kaa dati tie saglabaati un peec tam mekleeti... teiksim pie insert/ select ar indexetu lauku 1.gadijumaa , sakumaa tiek mekleets kursh baits(failaa) ir ieraksta sakums, peec tam cik iisti garsh ir shis ieraksts... ja daudz warchar tad visi tie tiek skaitiiti... 2. gadijumaa , no index tabulas savaac ar kuru baitu saakt, un praktiski arii ielasa visus datus... -- tieshi sii iemesla delj ir slikts variants NULL P.S. protams es nestaastiju preciizi, jo ir vel 1001 nianse, bet vispaariigaa domaa ir tieshi saada... Link to comment Share on other sites More sharing options...
Recommended Posts