Új hozzászólás Aktív témák

• #1404 Drótszamár őstag Peter Kiss #1403

  Új Válasz 2013-08-18 22:55:11 #1404

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drótszamár

  őstag

  válasz Peter Kiss #1403 üzenetére

  Értem, köszi. Át fogom nézni a táblákat e szerint, hogy hol min lehet gyorsítani.

  Az előző táblába tettem 800.000 rekordot, és egyelőre nincs lassulás. Köszönöm mégegyszer a segítséget.

• #1402 Drótszamár őstag Peter Kiss #1400

  Új Válasz 2013-08-18 21:46:32 #1402

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drótszamár

  őstag

  válasz Peter Kiss #1400 üzenetére

  Köszönöm, nagyon sokat gyorsult így az ellenőrzés. Az eddigi 3-5 percről lement kb 1s-re.
  Tolok még a táblába teszt adatot, hogy lássam meddig bírja.

  Akkor a rossz indexelés volt a gond. Eddig úgy tudtam az a lényeg, hogy legyen az adott oszlopra index, de ezek szerint az adott WHERE feltételben szereplő mezőkre kell közös index.

• #1401 Drótszamár őstag Peter Kiss #1400

  Új Válasz 2013-08-18 21:33:51 #1401

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drótszamár

  őstag

  válasz Peter Kiss #1400 üzenetére

  Köszi, mindjárt kipróbálom a két mezős indexet.

  Bejön a 10.000 adat. Ebből csinálok egy nagy SELECT-et, ami nézi a duplikációt, visszaad 0 és 10.000 sor közötti adatot attól függően, hogy van e dupla adat, vagy nincs. Amit visszaadott a SELECT, azokat a dátumokat kukázom a bejövő adatok közül (mivel duplák), és a maradék adatból csinálok egy nagy insert-et.

• #1399 Drótszamár őstag Peter Kiss #1398

  Új Válasz 2013-08-18 21:13:21 #1399

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drótszamár

  őstag

  válasz Peter Kiss #1398 üzenetére

  datum BTREE
  Egyedi: Nem
  Csomagolt: Nem
  Számosság: 126492
  Illesztés: A
  Nulla: YES

  muszer_id BTREE
  Egyedi: Nem
  Csomagolt: Nem
  Számosság: 1
  Illesztés: A
  Nulla: YES

  Megszokásból MyISAM. Van erre a feladatra jobb tároló?

• #1397 Drótszamár őstag

  Új Válasz 2013-08-18 20:54:51 #1397

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drótszamár

  őstag

  Üdv!

  PHP + APACHE + MYSQL

  Mérési adatokat kellene egy táblázatban tárolnom. Ritkán jön bele adat, de akkor sok. Egyszerre 10-20.000 adat érkezik, a tábla milliósra fog hízni idővel.

  Van hozzá egy fapados tábla

  ID, műszer_id, dátum, adat, küldés dátum.

  A dupla tárolást úgy próbálom szűrni, hogy az insert előtt egy select-tel megnézem van e már erre a dátumra mérési adat.

  SELECT dátum FROM tábla WHERE (műszer_id="xxx") and (dátum="2013.08.18 18:00:00" or dátum="..."); Maga a query rohadt nagy, 10-20.000 adatot kérek le egyszerre.

  Kb 100.000 adatnál járok, és egyre lassul a törénet.

  index van a műszer_id-re, és a dátumra is. MYSAM tábla.

  Konfiguráción állítsak, vagy a logika a hibás? Hol a lassulás oka? A lekérdezés lassú, vagy az értelmezés is az pl a 10.000 "szöveges" dátum miatt? Vagy írjam át a kódot, és egyesével kérdezzem le?

  Egy hasonló logika alapján felépített insert lefut egy fél pillanat alatt...

• #224 Drótszamár őstag lao ce #223

  Új Válasz 2006-02-04 10:19:12 #224

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drótszamár

  őstag

  válasz lao ce #223 üzenetére

  Igen ez lett a megoldás amit te írtál. Van egy csúny redundás HSZ tábla, és az adatbázis többi része szépen normalizálva. Amikor egy hsz érkezik akkor a táblákból összevadászom az adatokat és behányom a csúnya táblába.

• #222 Drótszamár őstag

  Új Válasz 2006-02-03 09:16:53 #222

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drótszamár

  őstag

  Na megint lenne egy idióta kérdésem.
  
  Elől lehet e kaparni valahogyan a slow query-ket. Tehát megjegyezi e a MYSQL. Estleg be lehet e állítani, hogy így tegyen.

• #220 Drótszamár őstag L3zl13 #219

  Új Válasz 2006-01-26 09:38:07 #220

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drótszamár

  őstag

  válasz L3zl13 #219 üzenetére

  Lehet rosszul fogalmaztam...
  
  Tudom, hogy a lekérdezés csak 1 sor, de mysqlnek sokkal többet kell dolgoznia. Veszi az első hszt a táblából, fogja a másik táblát kikeresi az adott hozzászóló adatait, veszi a második hszt, fogja a másik táblát előkaparja az adatokat, veszi a harmadik hsz... és így tovább. Ha esetleg nem ennyire buta a mysql, és elősször végigfut a hsz táblán, utána keresgél a másikban, akkor is 2x annyit dolgozott vele, mintha 1 táblából kiszedi a dolgokat.
  
  A hozzászólások száma jóval kevesebb mint a lekérésé, szal itt nem gond ha a felhasználók táblában kell turkálni az adatok miatt. Az adatok pedig nem módosulnak
  

• #218 Drótszamár őstag

  Új Válasz 2006-01-26 09:10:58 #218

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Drótszamár

  őstag

  Sziasztok!
  
  Egy kérdéssel fordulnék azokhoz, akik üzemeltetnek/üzemeltettek forgalmasabb oldalt, ahol a mysql komolyabb terhelésnek vol kitéve.
  
  Tehát adott egy fórumszerűség. (ki írta, mikor írta, mit írt, mi az e-mail címe, ...)
  Nagyjából ezek az adatok kapcsolódnak egy hozzászóláshoz. Ezt ugy lehet szépen szabályosan normailizált táblákban tárolni. Az egyikben vannak a hozzászólások, a hsz ideje meg a hozzászló ID-je. A másikban meg hozzászólók adatai.
  
  A másik módszer, hogy a hozzászólások táblában tárolom el a hozzászóló nevét, az e-mail címét, az időt, és a hsz-t is. Ez egy nagyon redundáns táblát eredményezne.
  
  Viszont visszakeresésnél a második módszerrel egy 100-as hsz lista lekérése 1db query míg az első módszernél 101, ugyanis a név, emailcím párost a hsz mellé külön mindíg ki kell keresnie a mysqlnek.
  
  Tehát a kérdésem hogy a tapasztalataitok szerint melyik módszer a gyorsabb? Esetleg hogyan lehet minél gyorsabb működést elérni? A tábla mérete többé-kevésbé lényegtelen, szal ha a csúnya, redundás tábla gyorsabb visszakeresést eredményez akkor azt fogom használni.
  
  Sajnos gyakorlati tapasztalatom nem sok van e témában.

Új hozzászólás Aktív témák