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

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

  Új Válasz 2013-08-18 21:55:47 #1403

  Ú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

  

  Peter Kiss

  őstag

  válasz Drótszamár #1402 üzenetére

  Az indexelés sokszor nem triviális, mert pl. ha a WHERE-ben 2 oszlopot fet az index, és pl. a SELECT-ben benne van az a 2 és még egy, akkor akár azt az egyet még mellé lehet tenni, és akkor tisztán indexből dolgozhat a cucc.

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

  Új Válasz 2013-08-18 21:24:59 #1400

  Ú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

  

  Peter Kiss

  őstag

  válasz Drótszamár #1399 üzenetére

  InnoDB jobban bírja az INSERT-et.

  ---

  Ez a két index haszontalan, 1-1 oszlop nagyon ritkán jó külön indexelve, készíts olyat, amiben az első oszlop a muszer_id és a második a datum. És azon túl, hogy haszontalan, feleslegesen rontja az insert-teljesítményt is.

  Az ellenőrzésed nem tudom, hogyan néz ki pontosan, de a fenti query-t alapul véve inkább egy kellene:

  SELECT dátum FROM tábla WHERE (műszer_id="xxx") and (dátum="2013.08.18 18:00:00" or dátum="...") LIMIT 1;

  Vagy lehetne még EXISTS-et is használni.

  Emellett nem tudom, hogyan futtatod ezeket? 1 INSERT előtt 1 SELECT? Lehet, hogy érdemes lenne előbb lemarni az összes kizáró tényezőt alkalmazás szinten, ha lehet, majd csak a ténylegesen beszúrandókat elküldeni, és így 2 hívásból megvan az egész.

  ---

  Utolsó dolog, amire figyelni kellene, az a szerver beállítása, helyből a MySQL egy 10+ éves gépre van optimalizálva 5 MB memóriával.

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

  Új Válasz 2013-08-18 20:57:26 #1398

  Ú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

  

  Peter Kiss

  őstag

  válasz Drótszamár #1397 üzenetére

  Pontosan hogyan néz ki az index, és miért MYISAM?

• #223 lao ce aktív tag Drótszamár #220

  Új Válasz 2006-02-03 20:13:07 #223

  Ú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

  

  lao ce

  aktív tag

  válasz Drótszamár #220 üzenetére

  nem vagyok mysql specialista, de talan segithetek egy kicsit.
  
  te azt kerdezted, hogy 100 hozzaszolas lekerdezese (gondolom egymas utani), egy ilyen szituacioban gyorsabb-e ha denormalizalt adatbazisod van. igen, lehet hogy gyorsabb, bar talan nem sokkal, hiszen valoszinuleg hdd-hez kell nyulni az adatmennyiseg miatt. ha pontosan ez a feladat es semmi mas, akkor ez eleg is.
  
  de sosem csak ennyi a feladat, es akkor bizony jo ha van valami normalizalas is, ne kelljen mar varni harom percet mire kiadja a gep mondjuk, hogy kik az aktiv forumtagok, nem?
  
  a view csak egy eltarolt query, szoval csodat ne varj tole. sebesseg szempontbol azt hiszem tok mindegy, hogy view-t vagy query-t hasznalsz, ha azt mondod kered a csillagot a view-bol akkor siman lefut a view query-je.
  
  masik dolog: feltetelezhetoen a 'hozzaszolasok' sokszorannyi helyet foglalnak mint az az 'aprosagok' (mint nick, email stb), szoval ezek hozzafuzese a tablahoz nem jelentene merheto lassulast egy keresesnel vagy valogatasnal.
  
  vagyis en amit csinalnek, az az, hogy lenne egy normalizalt tabla strukturam ahogy annak rendje es modja, de ettol fuggetlenul benne lenne a nagy uzenet tablaban minden felhasznaloi adat ami kell az altalad irt lekerdezeshez. ez nagyon kicsi tuladminisztralasa a dolgoknak, a hdd space meg igen olcso.

• #221 L3zl13 nagyúr Drótszamár #220

  Új Válasz 2006-01-26 09:58:18 #221

  Ú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

  

  L3zl13

  nagyúr

  válasz Drótszamár #220 üzenetére

  Szvsz view-nál (ha 5.x-es MySQL-t használsz) nem ilyen rossz a helyzet. Szvsz még sima SQL joinnál is van optimalizáció, amitől nem olyan vészes.

• #219 L3zl13 nagyúr Drótszamár #218

  Új Válasz 2006-01-26 09:21:17 #219

  Ú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

  

  L3zl13

  nagyúr

  válasz Drótszamár #218 üzenetére

  A esetben mitől lenne 101db query a listázás?
  sql-ben összejoinolod a két táblát, és egy lekérdezésből megvagy...
  
  Másrészt meg a felhasználók adatai gondolom regisztrációból jönnek.
  Na most hyogyan oldod meg, hogy ezek az adatok mindig visszaíródjanak a táblába minden egyes új hozzászólásnál?
  És ha módosulnak az adatok? Az összes rekordban módosítod őket?
  
  MySQL asszem nem tud view-t, de szvsz az lenne az ideális a listázásra. A tárolás pedig mindenképp több táblára szétbontva.

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