Rychlost MySQL

chápu to správně že chceš vrátit obsah celé tabulky na stránku a tam teprve vybírat 10 nej- záznamů ? schválně vyzkoušej na nějaké menší tabulce se 100.000 záznamy jak dlouho to bude trvat...a pak na to rychle zapomeňa) zbytečně čteš kvanta nepotřebných dat z disku na db serverub) zbytečně generuješ traffic mezi aplikací a db serveremc) zbytečně zatěžuješ aplikační server - udělá to setřídění vždy řádově pomaleji než db serverpokud se jedná o malé tabulky typu číselníku tak těch se to samozřejmě netýká - ty si dej jen jednou do aplikační cache a pracuj pak s ní

Nechci tě zklamat, ale ORDER BY nefunguje jinak, než že přečte vše a pak to seřadí. Výhoda ORDER BY spočívá v tom, že ne výstupu jsou pouze ta data, která chceš a také je použit inteligentnější sort.Body b) a c) platí stoprocentně.

a o indexech jsi už slyšel ? já samozřejmě předpokládám jejich existenci na patřičných sloupcích...pak je ORDER BY i na tabulce s miliony záznamů otázkou desetin sekundy

index tam je, ale je jich tam víc, protože potřebuju pracovat s různýma sloupcama a různě třídit

to je úplně OK, pak si řazení i TOP/LIMIT udělej na serveruna stránce řeš pokud možno už jen prezentaci datudělat dva i více dotazů není na závadu když to ve výsledku bude rychlejší než zpracovávat data ve stránce - podrž si connection a všechny dotazy udělej jen na jedné

No já se učil PHP a MySQL stylem pokus/omyl, čili si rád nechám poradit.Momentálně to mám vyřešené tak, že na začátku stránky si uložím data o připojení na MySQL do proměnné conn a potom pomocí této proměné volám do db vždy s určitým SELECT příkazem, např. SELECT MaxTemp FROM data ORDER BY MaxTemp LIMIT 10, nebo SELECT MinHumidity FROM data ORDER BY MinHumidity DESC LIMIT 10 atd.

proti tomu nelze celkem nic namítat

OK, no a právě problém je, že DB má momentálně cca 300k záznamů. A já potřebuju na jedné stránce např. zobrazit max a min pro několik hodnot, s tim že do db pořád záznamy průběžně přibývaji, takže to nejde řešit cachovánim.

v tom případě bych zvažoval např. insert trigger který by mi udržoval hodnoty MaxTemp, MinHumidity apod. v extra tabulce maximálních a minimálních hodnot...no a pak už by aplikace četla jen ty max. a min. hodnoty namísto prosévání dat

queeg 500 byl rychlejsi, mely by te zajimat triggery.Pokud se do nich nechces poustet, tak dobry index nad hodnotami, podle kterych chces vybirat, je spravna odpoved. Zvaz pouziti InnoDB enginu, pokud uz ho nemas. Bude mit o neco pomalejsi zapis nez MyISAM, ale cteni podle indexu by melo byt rychlejsiP.S. 300k zaznamu neni velka databaze

No já právě vim že 300k zas neni tolik a proto je mi divný, že třeba 10 volání do db na jedné stránce se načítá i víc jak 10s

Pak ti but chybi indexy (select explain...), nebo tahas zbytecne moc dat (v megabajtech na dotaz) nebo mas nejaky hlubsi problem s pripojenim k databazi (zapnute reverzni DNS na spojeni, ...)

Moc ti teď nerozumim,prostě mám PHP stránku, která potřebuje získat ty data, čili si zavolá do MySQL DB s příkazem SELECT.... ORDER... případně LIMIT apod.

Takže jestli to chápu správně (ano ta tabulka dokonce má mnohem víc než 100 000 záznamů...), tak navrhuješ dynamicky vytvářet na serveru tabulku jen pro tyto hodnoty ze které to pak budu dycky brát?

Takové údaje většinou není třeba dostat úplně online.Založ si tabulku (případně 2) do které budeš nejvyšší a nejnižší hodnoty ukládat. Pokud to stačí, tak si je cronem spočítej v noci. Pokud to potřebuješ častěji, udělej výpočet každé 2 hodiny nebo hodinu. Výběr z vypočítaných hodnot pak bude okamžitý a nebudeš zbytečně zatěžovat databázi.

Co můžeš udělat dnes, odlož na včerejšek.

o tomhle řešení jsem uvažoval. Hodnoty do DB přibývají co 5 minut, ale bylo by samozřejmě lepší kdyby to šlo dělat v reálnym čase, nebo pomocí CRONu třeba co 10 minut, což by stejně běželo na pozadí a neprodlužovalo čas, jen problém je, že mám v CRON nastavení min interval 1 hodinu