Mysql szerver működése lekérdezéskor
2009-11-29T00:16:11+01:00
2009-12-12T10:34:40+01:00
2022-07-25T08:36:21+02:00
  • akkor koszonom a hozzaszolasokat! ezek alapjan ugy erzem egyenlore nem kell tul nagy jelentoseget forditanom a dolognak, majd ha mar lesz egy tobb ezer rekordos tabla akkor nezegetem meg a masik verziot erdemes e vele pocsolni.. :D
    koszi megegyszer!
    Mutasd a teljes hozzászólást!
  • mivel meg mindig utkoznek a velemenyek a temaban, es mivel ugyis csak a sajat szememnek hiszek, ezert csinaltam egy egyszeru tesztet, egy 20 mezos tablanal, 50ezer query utan sincs ertekelheto sebessegkulonbseg mysql alatt a ket modszer kozott.
    tobbet nem volt turelmem kivarni, de szerintem ez mar eleg nagy minta.

    hogy ez mennyire implementaciofuggo, nem tudom, de elkepzelheto hogy pl mssql-nel valoban szamit a dolog.
    Mutasd a teljes hozzászólást!
  • Én most két szerveren is "kimértem" (többségében varchar és int mező, pár date, bigint, smallint):

    select * from tábla limit 0,2000

    0,0110-0,0170 s között volt általában, nem volt 0,0110 alatt, de volt pár 0,11xx.ig értékig
    ----

    select mező1, ..., mező90 from tábla limit 0,2000
    0,0110-0,0170 s között volt általában, 0,0178 felett sose, de volt pár 0,0088-as értékig lefel.

    Az egyik MySQL kliens verzió: 5.0.32, MyISAM

    ========

    Bár nem sok eset van, amikor a 90 mező mind kell egy lekérdezésbe

    [szerk]
    Kíváncsi lennék egy egy mezős táblában mit hozna eredményként. De ehhez már lusta vagyok.
    Mutasd a teljes hozzászólást!
  • Ezzel egyetértek.
    Én sem azért írom ki mindig a mezőneveket, mert a parsing sebességétől félek (hiszen precompiled statement-eket használok úgyis, ha sebesség kell), hanem mert:

    - általában 10-ből csak 4 mező kell
    - pláne ha később bővíteném a sémát, akkor *-al automatikusan lehozná az újakat is, így szépen lassan 'észrevétlen' eléggé eldurvulhatna a dolog.
    - olyan apit használok, ahol így sorszám szerint tudom elérni a lekérdezett oszlopokat, ami gyorsabb

    Persze ha extrém sebességigény lenne valahol, ott minden verziót kimérnék, semmit nem bíznék a véletlenre.
    Mutasd a teljes hozzászólást!
  • Szerintem nincs jelentősége, legalábbis szerver oldalon.
    Az SQL szervernek mindenképpen ki kell nyúlnia a select végrehajtásakor a séma adatokért - amik amúgy is épeszű szervernél a RAM-ban vannak. Azaz az hogy most select * vagy select mezo1, mezo2 a szerver szempontjából lényegében tökmindegy, sőt implementációtól függően, szvsz a select * akár gyorsabb is lehet.

    Az már egy másik kérdés hogy ha van 15 meződ de csak 2 kell, és az is hogy ezután a kliens oldalon mi történik. Azaz Pl. dinamikusan olvassa-e ki a rendszer a séma infót, vagy be van drótozva hogy az 1. mező a név ami string, a második mező az irsz ami integer.

    Mutasd a teljes hozzászólást!
  • Jó hosszan leírtam, amit le lehetett volna írni rövidebben is:

    Kis pénz: kis foci; nagy pénz: nagy foci. Vagyis amiben van pénz, sajnos csak azzal érdemes sokat tökölni, a többivel nem lehet, mert akkor a család nem tud mit enni.
    Mutasd a teljes hozzászólást!
  • Én kicsit másképp látom ezt a szakmai hanyatlás dolgot.
    Én eljutottam oda, hogy nincs elmélet vs. gyakorlat.
    Szerintem csak egy dolog van:
    Amire van fizetőképes kereslet, azt kell kielégíteni.

    A fejlesztési költség pedig nem mehet a bevétel felé, mert akkor az egésznek nincs értelme.

    A sebességre való optimalizáció egy szinten túl mindenképpen növeli a rendszer komplexitását, csökkenti a rendszer felxibilitását, növeli a fejlesztési időt. Továbbá óvakodni kell a premature optimization-tól, mint a tűztől. Egy jó mérnök attól jó mérnök, hogy talál egy jó trade-offot.

    Egyszerűen ki kell matekozni, hogy melyik piacon mennyit éri meg költeni a fejlesztésre, mennyire számít a sebesség, mennyit érdemes beleölni a sebességre való optimalizálásba, olcsóbb-e hardverrel megúszni a dolgot, vagy olcsóbb gyorsabb szoftvert fejleszteni. Ez nagyrészt közgáz, illetve közgáz-matek.

    Ha úgy gondoljátok, hogy szakmai hanyatlás van, akkor jó nektek, mert biztos egy csomó piaci rést láttok, ahova jobb gyorsabb kóddal be lehetne törni. Én másképp látom: nincs itt semmiféle hanyatlás, legfeljebb a kvázi monopol piacokon. A nem kvázi monopol piacokon igenis minden eddiginél nagyobb verseny van, és aminek tényleg van jelentősége, és amiben van pénz, azon egy sereg okos ember dolgozik.

    Ha valamiben válság van, az inkább szvsz. az, hogy túl sok minden ingyenes, vagy a nagy versenyben túlságosan lement az ára, így túl sok mindent nem éri meg 'igazán igényesen' megcsinálni. (Ha ebből a szempontból nézzük, akkor végülis egyetértünk, mert én pl. azért nem töröm a fejem bizonyos konkrét kisebb ingyenes lib-ek helyett mondjuk 20%-al gyorsabbat írni, még ha képes lennék is rá, mert nem lenne belőle pénzem...)
    Mutasd a teljes hozzászólást!
  • És attól az egész művelet lassabb, vagy gyorsabb lesz?
    Mert ha lassabb, akkor mi a kérdés még?


    Hát ha a nagyon extrém esetet nézzük a lekérdezés fordító mondjuk elszöszöl 0.0001s -t hogy kitalálja mi kell a csillag helyére, mondjuk a php fordítónak meg 0.0002s-el több időbe kerül a futás mert hosszabb a string, vagy az adatátvitelnél veszik el több idő, akkor akkor a * nyert. :)
    Persze ezek mind csak feltételezések, de nem hiszem hogy egy 50 mezős táblában fel kellene sorolni mind az ötven mezőt amikor *-ot is lehet írni. Ha két mező van benne biztos a felsorolás gyorsabb.
    Persze, ha a mysql "rögtön tudja" mi kell a csillag helyére mint a select count(*) -akkor a csillag a gyorsabb.
    Mutasd a teljes hozzászólást!
  • Miért lényeges hogy hány felhasználós környezet?


    Mert ha óránként csinálsz egy lekérdezést, és az 10 mp helyett 11 mp-et fut, akkor az önmagában érdektelen (meg lehet, hogy "nem mérhető" értékhatáron belül van).

    Da ha másodpercenként csinálsz több ezret (amit egy felhasználó azért ritkán csinál), akkor már igen is érdekes lehet az összes terhelés (memória, proci használat, hálózati kapcsolat és kommunikációs sebesség) szempontjából, hogy van 10% plusz. (De persze már egy kisebb plusz is érdekes lehet)

    Legrosszabb esetben a fordító működését lassítja egy művelettel,

    És attól az egész művelet lassabb, vagy gyorsabb lesz?
    Mert ha lassabb, akkor mi a kérdés még?

    magára a lekérdezés végrehajtására nincs hatással szerintem

    Bocs, nekem az sql szerver felül nézve egy lekérdezés a kérés érkezésétől az adat elküldéséig tart.
    Tehát mindegy, hogy ebben az időszakban mi történik, amikor ugyan olyan információhoz jutás tovább tart, az szerintem kevésbé optimális.

    Ha pedig a kérdést nézzük,
    csak egy * van ott utana kivalogatom ami kell az eredmenybol, vagy mindjart ugy kerdezem le hogy celiranyosan csak az adott mezoket

    részre válaszolva meg nem csak a "lekérdezés" lassabb ha csillaggal kéred le a mezőket, mintha felsorolod, hanem még felesleges hálózati forgalmat is generálhaszt (ha a php és sql "szerver" nem ugyan az a gép vagy - mivel a kérdésben nem szerepel hogy pl. webes környezet - az adatok feldolgozója egy munkaállomás, ahova elküldjük a pár 10-20-x Mb-os képeket, ha csak az illető neve kell. És most kérem senki ne abba kössün bele, hogy miért van az adatbázisban a kép, mert más sok infót is írhattam volna)

    ---
    meselj az oprendszeredrol :))

    Csak példaként írtam, de lehetett volna egy alkalmazás is. a hangsúly a
    "jól megírt"
    részen volt.
    Mutasd a teljes hozzászólást!
  • Persze lehet azt mondani, hogy olyan kicsi az eltérés, hogy "nem mérhető", de ez addig igaz, amíg egy felhasználós környezetről van szó.


    Miért lényeges hogy hány felhasználós környezet? A lekérdezés fordító ígyis-úgyis jópár műveletet végez a felsorolt mezőkkel, az hogy Te hogy adod meg a mezőket, nem hiszem hogy érdemben befolyásolja az eredményt akármekkora terhelésnél is. Legrosszabb esetben a fordító működését lassítja egy művelettel, magára a lekérdezés végrehajtására nincs hatással szerintem.
    Mutasd a teljes hozzászólást!
  • Igen, ez a baj: összetákolunk valamit, majd azt mondjuk: ez ilyen, vegyen több RAM-ot, gyorsabb procit, nagyobb lemezt, mert nincs kedvünk optimalizálgatni
    Kivételeknek tisztelet ofkorz...
    Mutasd a teljes hozzászólást!
  • igen, elkerulhetetlen az atszokas, ha elni akar :)
    Mutasd a teljes hozzászólást!
  • ja, most latom hozzafuztel az elozohoz.
    meselj az oprendszeredrol :))
    en is elkezdtem anno egyet.
    egy com fileban volt minden
    nehany alap int 21h-s funkciot leutanoztam, amik kellettek a parancsorhoz, amit tudtam a cimbiknek mutogatni, aztan valahol a lemezkezeles tajekan meguntam a bulit :)
    Mutasd a teljes hozzászólást!
  • igen, szerintem is az a helyes hozzaallas amit te is kepviselsz, de ez egy idealisztikus nezopont.


    Az. De legalább "tanítani" próbáljuk meg ezt. Aztán majd úgy is átszokik a másikra
    Mutasd a teljes hozzászólást!
  • igen, szerintem is az a helyes hozzaallas amit te is kepviselsz, de ez egy idealisztikus nezopont.
    es a valosag az hogy a megrendelo inkabb olcsoert egy cms-t szabat at a sajat igenyeinek megfeleloen, mint hogy megfizessen valakit, aki a nullarol elkeszitene neki egy egyedi oldalt.

    es ja, az elet minden teruleten mutatkozik ez a hanyatlas amirol beszelsz, de nem lehet ellene mit tenni.
    lesz meg rosszabb is. :)
    Mutasd a teljes hozzászólást!
  • es vajon miert mondjak ezt a programfejlesztok


    Elmélet kontra gyakorlat?

    Vagy nem tanulják csak csinálják?

    Vagy termelékenység(ár) kontra szakszerűség?
    (Erről az jut eszembe, hogy a fiam még olyan kisautókkal (is)játszik, amikkel én játszottam vagy 30 éve. Mert akkor még a minőség volt az elsődleges (pedig már én is "teszteltem" homokban, falon, ...).
    A ma vett játékautók jó része még fél évet se bír ki.
    De árban talán olcsóbb)

    ---
    hany cms operal tarolt eljarasokkal

    Szerintem a cms minden lehet, csak nem programozói minta.
    Tapasztalatom szerint minél több mindent akar egy rendszer lefedni, annál kevésé van értelme benne (sebesség, proci, memória használás, tárhely igénylés) optimalizált eljárásoktól beszélni.

    ---
    jobban megeri a megrendelonek a hardverre kolteni, mert az biztosan megterulo befektetes.


    Hát ha az én "jól megírt" oprációs rendszerem és upgradjei fog futni rajta, akkor nem megtérülő, hanem szükséges befektetés
    Mutasd a teljes hozzászólást!
  • es vajon miert mondjak ezt a programfejlesztok? :P

    megint csak meg lehet nezni, hany cms operal tarolt eljarasokkal :)
    Mutasd a teljes hozzászólást!
  • hogy altalanosan jobban megeri a megrendelonek a hardverre kolteni

    Szerintem a programfejlesztők is ezt mondják. Ezért (is) kell egyre erössebb gép ugyan ahhoz a feladathoz (ld. Windows 3.11-> Vista), ha pont nem az extra dolgokat akarjuk használni bebölük.
    (Miért lassabb egy mappamegnyitás egy újabb Windows-on )

    query string

    Tárolt eljárás "paraméterekkel"

    Mutasd a teljes hozzászólást!
  • ez igaz, de hozzatennem, hogy altalanosan jobban megeri a megrendelonek a hardverre kolteni, mert az biztosan megterulo befektetes.
    viszont megrendelo es a fejleszto kapcsolata az emberi tenyezok miatt valamilyen szinten mindig "zsakbamacska", meg jol bevalt hosszutavu munkakapcsolatok eseten is.

    ja es meg az interpretalt nyelvek eseten jutott eszembe, hogy lehet amit nyerunk a reven elveszithetjuk a vamon.
    nem teszteltem, de elkepzelheto, hogy pl nagy mezoszamu tablanal a query string, es egyben a forraskod merete akkorara novekedhet, hogy a feldolgozasaval tobb idot vesztunk, mint amennyit a *-gal kuzdene a mysql server.
    bytecodera forditasnal ertelemszeruen fel sem merul a dolog.
    Mutasd a teljes hozzászólást!
  • Hát igen, az elmélet és a gyakorlat az nem mindig egyezik.

    De ha a kérdés úgy hangzik, hogy "
    van e jelentosege annak
    ", akkor a

    - Mind1 hogy csillagot írsz vagy felsorolod
    - ha az osszes mezot lekerdezed igy felsorolva, akkor nincs jelentosege


    Válaszok kicsit "érdekesek"
    ---

    Persze gyakorlatban lehet számolni, hogy pl.

    Ha "*" helyett mezőfelsorolás lesz, akkor az plusz 5 óra, 10.000 Ft/óra (csak minta) tehát 50.000 Ft.
    Ha egy erösebb procit veszünk (a most összerakandó gépbe), az +15.000 Ft, akkor nem éri meg.

    De ha meglévő gépbe az azonos adatlekérdezési sebességhez új proci kellene, de ahhoz új alaplap, amibe nem jó a régi memória, amihez már új hdd kell, ... akkor lehet hogy inkább a "munkásabb" út a járandó.
    Mutasd a teljes hozzászólást!
  • valszeg gyakran elofordult mar ezen az oldalon ez a tema, de amit irsz, egy tokeletes vilagban lenne igaz.
    sajnos a valosagban a programozokat legtobbszor surgeti az ido, ezert ilyen dolgokkal nem foglalkoznak.

    erdemes megnezni az ismertebb cms-ek kodjat, (drupal, joomla, vagy fizetosek kozul pl vivvo) tele vannak select *-gal, pedig ezek, (kulonosen a vivvo) gyakran hajtanak nagy terheltsegu oldalakat.

    a windows sem az az agyonoptimalizalt rendszer, ugy altalaban a pc-s szoftverpiac sem az, a hardvergyartok nagy megelegedesere.

    de egyebkent en a sajat munkaimat a vegletekig optimalizalom, de szerintem tisztaban vagy vele, hogy nem ez az altalanos hozzaallas. :)

    Mutasd a teljes hozzászólást!
  • Mind1 hogy csillagot írsz vagy felsorolod


    NEM mindegy.

    Persze lehet azt mondani, hogy olyan kicsi az eltérés, hogy "nem mérhető", de ez addig igaz, amíg egy felhasználós környezetről van szó.

    De nem hiszem (hogy másik véglet legyen) egy Google-nél már mindegy lenne.
    És ha egy adatbázist tervezünk, akkor célszerű az optimális működésre és nem a fejlesztő optimális munkájára törekedni.

    Egyébként egy bonyolult where is tud lasstani. Adjuk oda a felhasználónak az összes rekordot, aztán válassza ki magának a munkaállomáson amelyik neki kell.

    Vagy programozóként egyszerűbb, ha nem használunk jogosultságokat, mert akkor nem kell egy rutint megírni hozzá.

    --
    A helyes fejlesztés nem azt jelenti, hogy a programozónak kevesebb dolga legyen, hanem azt, hogy a feladatnak elegettevő, jól működő alkalmazás legyen a rendszer erőforrásainak felesleges pazarlása nélkül.

    Érdekes kérdés, ha pl. a Windows-otok (oprendszeretek) és a rajta futó programok mind minden másodpercben csinálnának 1/10 másodpercnyi felesleges feladatot, akkor elégedettek lennétek ezzel, vagy morognátok érte? Persze a feladatot jó megoldaná, csak kicsit lassabban.

    Mutasd a teljes hozzászólást!
  • jaaa.. pont azt hittem itt kell ezeket feltenni :S a pontok nyilvan engem sem hatnak meg mivel nem tolem veszi el, szivesen osztogatok belole ! akkro majd ott fogok okos kerdeseket feltenni :D
    Mutasd a teljes hozzászólást!
  • Mind1 hogy csillagot írsz vagy felsorolod. Az nem mindegy hogy mekkora méretű, milyen típusú mezőket kérdezel le. Ha pl nincs szükséged egy text típusú mezőre akkor célszerű kihagyni, mivel a text mezőket fizikailag nem a rekord mellett tárolja hanem egy teljesen másik helyen és mutatóval hivatkozik rá. Amikor lekérdezed akkor pluszban még a mutatón is át kell mennie. Ha egy int mezőt teszel bele fölöslegesen sokkal kevesebb erőforrást pazarolsz.

    A másik lényeges dolog hogy ami szerint keresel, rendezel legyen rá index, és tudja is használni.
    Mutasd a teljes hozzászólást!
  • Persze, ha adhoc a felületen összeütsz egy egyszer használatos qery-t, nyilván csillagot teszek én is. Programból viszont jobb felsorolni, hiszen felsorolod akkor is amikor felhasználod az értékeit. Itt meg ráadásul sokszor fut, sok kicsi meg ugye...
    Mutasd a teljes hozzászólást!
  • jaja, logikus, mert megsporol a servernek egy kis munkat, de nem annyira szamottevo a sebessegbeli kulonbseg, hogy emiatt erdemes legyen kezzel felsorolni egy 30~ mezos tabla mezoit (ha az ember nem hasznal ilyen sql studio szeru okos progikat).

    szerintem, ha pl 30 mezobol 25 kell nekunk,akkor se erdemes a felsorolassal tokolni.
    ha 30bol csak 5 mezo kell, akkor van ertelme :)
    Mutasd a teljes hozzászólást!
  • Az összes mező lekérdezésekor is van jelentősége, az ajánlás a kiírt mezőnevek és nem a csillag. Az MS SQL Studio ki is cseréli ha csillagot írok, felsorolja a mezőket.
    Mutasd a teljes hozzászólást!
  • ha az osszes mezot lekerdezed igy felsorolva, akkor nincs jelentosege.
    minden mas esetben van.
    amugy szerintem azert nem reagalnak az emberek ezekre a trivialis kerdeseidre, mert nem a tudastarban teszed fel oket.
    ellenben en szivesen tolom itt, nem erdekelnek a pontok :)
    Mutasd a teljes hozzászólást!
  • Hello!
    Az lenne a kérdésem, van e jelentosege annak, ha egy tablabol nem ugy kerdezek le ahol van mondjuk 10 oszlop hogy select * from tabla, hanem annyit hogy select nev, id, lakcim, stb stb from tabla.. tehat jelent valamit felhasznalt eroforras vagy ido tekinteteben hogy csak egy * van ott utana kivalogatom ami kell az eredmenybol, vagy mindjart ugy kerdezem le hogy celiranyosan csak az adott mezoket? melyik a jobb?? gondolom praktikusabb a csak nekunk kello oszlopokat, de vajon mennyire ido es energiagazdasagos? megeri e ezzel szorakozni egy * helyett??
    Mutasd a teljes hozzászólást!
abcd