Printable View
Nevíte o nějakym programu, teda jestli existuje, do kterýho bych kopnul dotaz a on by ho co nejvíc zrychlil :-)
Mám SQL dotazy, který fungujou dobře, ale sou děsně pomalý a určitě by šly napsat aby fungovaly stejně, ale rychlejc.
Nemáte s tim někdo zkušenosti?
Tak to ti asi ziadny soft nespravi, bohuzial musis sa s tym potrapit sam ;D alebo ich sem postnes a niekto ti to optimalizuje :wink:
To ze je skript strasne pomaly este neznamena ze je zle napisany. Zalezi aj od toho kolko mas podmienok, ake velke tabulky pouzivas ...
Bohuzel o takovym programu jsem nikdy neslysel. Az ho nekdo najdete, dejte mi link :lol: :lol: Ne fakt, pokud si myslis ze jde neco napsat lip, tak jak rikal Steelman, hod sem ted dotaz kterej pouzivas a strukturu pouzitejch tabulek
To je škoda sakra. Tak to budu muset zamakat :|
Kdyby někdo neco našel, tak hned s tim sem ;D
Pokud pouzivas podobne dotazy tak zkus pouzit pohledy ... zjednodussi to dotaz a melo by to pomoct i pry rychlosti
Optimalizaci SQL dotazu jsme probirali, bylo me z toho trochu zle.... :)
indexovat, indexovat, indexovat :D no samozrejmne nejvic zalezi na strukture databaze.....
btw: ted nedavno sem delal ER diagramy a osvedcil se mi tenhle jednoduchy soft "CASE Studio 2" Neni to jako Power Designer 10, nebo podobny mega programy, ale umi to to co umi a je to fajn :)
Každej mi řiká indexovat indexovat, ale nidko mi nebyl rozumně schopnej vysvěltit co to znamená :DCitace:
Původně odeslal smrtak_
Indexovani je pokud se nepletu to, ze se dany sloupecek zaznamu treba ID, nebo NICK uzivatele oddeli od vsech dat ulozenych na disku a ulozi se samostatne do indexovyho soubory dane tabulky. Tim padem pc nemusi napriklad prochazet 100 MB datovy soubory, ale nahlidne jen do indexovyho souboru, ktery ma zlomkovou velikost (zalezi na strukture tabulky) , vyhleda zaznam (napriklad nick), a pomoci odkazu skoci do toho 100MB datovyho souboru na presne misto kde ten zaznam je.Citace:
Původně odeslal kecinzer
tak nejak.
Hm, ale spis sem mel napsat tohle:
indexuj to co casto vyhladavas restrikci (where), takze nick, ID..... u tabulek co maji velkou datovou strukturu na jeden zaznam je to hodne znat.
Takže jestli sem to pochopil dobře, tak prostě tabulky akorát IDovat (dávat primární klíče) ???
No, to zalezi vetsinou na tom co prave resis. Muzes mit primarni klic napriklad z nicku, nekdy i slozeny klic z Jmena,Prijmeni a rodnyho cisla.Citace:
Původně odeslal kecinzer
Musi to urcovat proste jednoznacnost. Bud tam das navic sloupecek ID, ziskas tim vykon, nebo ho tam nedas pouzijes slozenej klic, ale tim zase ziskas mensi DB.
Ja osobne ID pouzivam hodne casto.
Jo a neplet si pojem index a ID zaznam, to je neco jinyho, indexovat muzes cokoli, treba napriklad nick, a nic jinyho nez to ze zrychlis dotazy tim neziskas.
mrkni na tohle treba ti to pomuze, to jsem delal nedavno:
http://data.4um.cz/ERD.png
A) Primarni klic by nemel nikdy obsahovat data. Nema cenu vysvetlovat proc, je to na dlouho, ale je to tak. Zadelas si na problemy pokud to data jsou.
B) Index neni klic jak bylo receno. Index ti vytvori setridenej nahled na dany pole a v nem se vyhledava radove rychlejs.
Takze zaindexuj vsechny podstatny zaznamy. Znamena to ovsem taky podstatny narust velikosti DB. Napr ja mam DB, ve ktery maj data dejme tomu 700MB a s indexama to ma 3GB.
Obecne zpomaluje hlavne JOIN a kdyz jich vnoris nekolik, je to hruuuzzaaa. Vyresit to de navrhem struktury DB tak, aby nebylo treba prilis tabulek propojovat. Napr tak, ze udelas jednu tabulku, ktera neobsahuje data, a na niz lze navazat libovolnou dalsi tabulku => mas max jeden JOIN.