Mysql lekérdezés vagy php ügyeskedés
2009-05-20T21:17:57+02:00
2009-08-15T16:42:09+02:00
2022-07-19T05:27:41+02:00
  • A kliens oldalon próbáltál számoltatni? Egyszerű lekérdezéseket JS tömbökbe a kliens oldalon tároltatni, és ott függvényekkel szétválogattatni. Nem elegáns, viszont a szervert valamelyest "kíméli", és a felhasználónak "gyorsabb" az érzete.
    Mutasd a teljes hozzászólást!
  • na nem vacakolunk kidobjuk az elméletet a kukába, és számolt adatokat fogunk tárolni, mert egyszerűen nagyságrendekkel gyorsabb.

    ja és az az elmélet is bukik miszerint selecteket nem hatékony joinolni. igaz nem sokkal, de most épp egy subselect gyorsabbá teszi a dolgokat.

    ja és az az elmélet is bukik hogy minél több az eq_ref annál jobb, mert ha straight joinnal dolgozok akkor igaz hogy több az eq_ref mintha sima joinnal csinálnám, és gyorsabb is kb 20%-kal, de a subselectnél kevesebb az eq_ref mégis gyorsabb (igaz csak egy hajszállal kb 5%-kal) még a straight joinosnál is.
    Mutasd a teljes hozzászólást!
  • oké, de ott nagyon elcsúszhatnak a dolgok. tudom mert most még úgy megy a régi verzió. és az a különbség a kettő között, hogy ha téveszt a rendszer, akkor előbbinél a tévesztett adat megőrződik, míg a másiknál ez nincs. amikor 10 percig futott egy lekérdezésünk, teljesen rosszul számolt a gép. most hogy ez a mysql hibája vagy a processzoré azt nem tudom, de így volt. és valamiért mégiscsak azt mondják nálam okosabb emberek a témában hogy mégiscsak az az "adatbázisosabb" ha minél kevésbbé redundáns. jó: lehet hogy ez akkor fontos ha rekordmilliókról van szó. nálunk max 100.000-es nagyságrend van, de már így is nagyon belassul egy group by. hiába próbáltam okoskodni a temp tábla méretének beállításával.
    Mutasd a teljes hozzászólást!
  • redundancia nagyon csekély.

    Üdv, ez sebesség szempontjából elég nagy hátrány!
    Minél redundánsabb, minél több számolt adatot tárolsz, akkor a lekérdezésben annál kevesebbet kell számolni / táblákat kapcsolgatni. Annál gyorsabb a lekérdezés.

    Mutasd a teljes hozzászólást!
  • sziasztok!

    na az van hogy a másik topicban először nekiveselkedtem a hardver oldaláról megközelíteni a futás lassúságát, de ez nem járható út egyelőre.

    most más oldalról kell megközelítenem a problémát. mindenki mondja hogy a kód nagyon fontos, a lekérdezés maga. ez oké.
    most teljesen jól szétkaptuk a táblákat, lett is elég sok, na jó nem olyan nagyon sok, kb 20. de frankón tematikailag minden szétszedve, sztem ezen már nem nagyon lehetne optimalizálni. redundancia nagyon csekély.

    szóval a kódról. az van hogy igyekeztünk mindent úgy alakítani hogy fölöslegesen te tároljunk adatokat, illetve ne tároljunk számolt értéketet, és ne tároljunk többször dolgokat. ennek lett az eredménye egy nagyon letisztult, alapesetekre építő táblastruktúra, amihez kivételek kapcsolódnak.
    ez úgy néz ki kb hogy ha indul a gyártás, akkor feltételezzük hogy az esetek 95%-ában ugyanúgy mennek a dolgok, így csak azok kerülnek a kivételek táblákba, amik éppen valamilyen dolog miatt nem kellenek vagy máshogy mennek. nem tudom ez jó-e így de nekem jónak tűnik. a probléma nem itt van. a probléma ott van hogy van egy rakás gyártmány, amik egy rakás alkatrészből állnak, amikkel egy rakás dolgot kell csinálni (ezeket technológiáknak nevezzük).

    a problémás lekérdezésnek az lenne a feladata, hogy a különböző technológiák szemszögéből megmutassa azokat az alkatrészeket, amik még nincsenek megcsinálva.
    namost a lényeg ott van hogy minden szép és jó, és még elfogadhatóan fut is a lekérdezés, amíg nem kezdek el sumozni meg group by-ozni. abban a pillanatban hogy elkezdem összesumozni a részeredményeket, meg group by-ozni, meghal az egész és a végtelenségig fut. ma kivártam, 90 másodperc volt, ami nonszensz. maximum 1 másodpercig mehetünk el, maximum annyi lehet ez a lekérdezés mert mindenki ezt fogja használni és azonnal kell az info. meg is van fél másodperc alatt ha nem group by-ozok. már napokat töltöttem azzal hogy a mysql környzeti változóit próbáltam csiszolni, de nem sok sikerrel. továbbra is a temp table-be írás viszi el az idő 99%-át. én nem tudom mi lehet a háttérben, elképzelni sem tudom mi a halál tud 90 másodpercig futni, mennyi adatot pakol honnan hová de azt tudom hogy ha két vinyó közt másolok, egy hegyet arréb lehet pakolni 90 másodperc alatt. szóval elképzelésem sincs vajon mekkora adatok (gigák?) mozognak a háttérben, de az is idegesítő hogy erre sincs egyértelmű ötlet, segítség a mysql oldalon.

    node. ez az egész nincs ha nem group by-ozok.

    kérdésem: hogy ne kelljen group by-ozni, hagyhatom a lekérdezés eredményét sokszor megsokszorozott sorok formájában, hogy utána php-val okoskodjam össze amit meg akarok jeleníteni? arra gondoltam hogy mindig figyelném a megfelelő adatot, és amíg az nem változik, array-be pakolnám az értékeket, a végén sum, és csak azokat a sorokat mutatnám amit végülis kell. tehát a left joinozáokból adódó sorsokszorozódások elkerülése végett. nem tudom érthető-e megoldható-e, csak egy ötlet, lehet meg se tudnám csinálni, de talán igen. ezzel elérném hogy maga a lekérdezés nagyon gyorsan lefut, és utána a php-ra lenne bízva a piszkos munka.

    sztetek?
    Mutasd a teljes hozzászólást!
abcd