Nesigilinsiu labai giliai ir ilgokai nenaudoju jau MySQL, bet greiciausia indeksavimo reikia kriteriju laukam nes kitu atveju full scan darai.. jei turi kokia nors data ne datetime (nepamenu ar buna mysql) tai ji galima butu irgi indeksuot jei pagal tai traukiama.

    Na ir siaip del architekturos kam tada jei struktura tokia pati kilnot is vienos lentos i kita, bent esu priesininkas duomenu kopijavimu visokiu, tai nepakaktu 1 lentos ir papildomo pozymio kuris reikstu viena ar kita busena, nuo to atitinkamai viena ar kita lenta ? 

    Aisku pagal ta pozymi butu privaloma indeksuoti.

"NicMC" <nic@nic.lt> wrote in message news:i1musg$ogj$1@trimpas.omnitel.net...
> Sveiki,
> 
> Pribrendo reikalas kažkiek optimizuoti duombazę, nes jau pradeda 
> kabintis į resursus. Taigi, turiu dvi lenteles po kelis laukus 
> kiekvienoj. Nuotoliniai taškai ima po vieną įrašą, trina iš vienos 
> lentelės, apdoroja ir krauna į kitą lentelę. Duomenys nedideli - pora 
> varcharų (10 ir 200 ilgio) ir pora intų. Kadangi įrašų smarkiai 
> padaugėjo (iki 400k pirmoj lentoj ir 1,2kk apdorotų duomenų lentoj) 
> paprasti selektai "select * from table order by priority ASC, start_time 
> ASC LIMIT 1" pradeda gruzint tą duombazę, CPU pradeda valgyt 50-100% 
> (CPU ne stebuklas beje). Ką pasiūlytumėt pakeisti, kad kažkiek 
> optimizuoti darbą? Išsiselektint viską, susortint ir sudėt atgal su 
> griežta numeracija? Prikurt partitionų? Key'jų?
> Selectinti daugiau duomenų ir cachinti lokaliai - ne išeitis, tikrai 
> reikia kad imtų po vieną eilutę, t.y. kad kitas nutolęs taškas gautų 
> tiksliai sekančią eilutę. Tam tie nutolę taškai lokina teiblą. Gal dar 
> ir čia problema?
> Kol kas neieškojau performanco stabdžių, tiesą sakant nelabai ir žinau 
> kaip tą padaryt apart programinės įrangos modifikacijų ir stebėjimo 
> rezultatų...