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

• #1581 Vision veterán martonx #1580

  Új Válasz 2013-02-05 20:27:41 #1581

  Ú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

  

  Vision

  veterán

  válasz martonx #1580 üzenetére

  Nálam is félreérthető volt, de ugyanarra gondoltunk.

• #1579 Vision veterán martonx #1578

  Új Válasz 2013-02-05 19:29:05 #1579

  Ú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

  

  Vision

  veterán

  válasz martonx #1578 üzenetére

  Nálam az alselectek sokkal több erőforrást elvittek, mint a join-ok. Esetleg úgy lehet egyszerűsíteni, hogy a join jobb oldalán egy alselect van. Így sokszor lehet a 3-ból 2-t csinálni.

• #1575 Vision veterán martonx #1574

  Új Válasz 2013-02-01 15:31:35 #1575

  Ú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

  

  Vision

  veterán

  válasz martonx #1574 üzenetére

  Töröltem az indexet, és újrageneráltam. A számosságra 204-et ír a ~37000 helyett, miközben az utóbbinak kéne ott állnia. InnoDb a tábla.

• #1573 Vision veterán

  Új Válasz 2013-02-01 14:28:29 #1573

  Ú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

  

  Vision

  veterán

  Valamelyikőtök találkozott már ilyesmivel? Incorrect key file for table '/tmp/#sql_3c7_0.MYI'; try to repair it.

  Mysql-ről van szó.

• #1543 Vision veterán martonx #1542

  Új Válasz 2013-01-07 17:03:41 #1543

  Ú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

  

  Vision

  veterán

  válasz martonx #1542 üzenetére

  Igen, már tegnap kiderült, hogy a szerver haldoklott, ezért volt lassú (most villámgyors). Ettől függetlenül még érdekelt a téma, és gondoltam megkérdezem a nálam tapasztaltabbakat, hogy van-e mód tovább gyorsítani az SQL-t. Mint írtam, egy más jellegű problémánál jól fog jönni a file-cache, de az kisebb jelentőségű, mint az első.

  Kösz a válaszokat!

• #1541 Vision veterán martonx #1540

  Új Válasz 2013-01-07 15:40:27 #1541

  Ú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

  

  Vision

  veterán

  válasz martonx #1540 üzenetére

  Ok, leírom:

  Van 3 táblám: ugyvitel_marka, ugyvitel_termek, ugyvitel_termek_altipus, ugyvitel_termek_tulajdonsag_kapcsolat

  ugyvitel_marka: id, markanev; értelemszerűen márkanevek vannak benne, ~250 db.
  ugyvitel_termek: id, ugyvitel_marka_id, termeknev: a termékek listája. Egyelőre ~17000 rekorddal.
  ugyvitel_termek_altipus: id, ugyvitel_termek_id, ugyvitel_statusz_id, stb.. : termék alkategóriák listája. Szintén ~17000 rek.
  ugyvitel_termek_tulajdonsag_kapcsolat: id, ugyvitel_tulajdonsag_id, ugyvitel_termek_altipus_id, tulajdonsag: ez tartalmazza a termékekhez tartozó tulajdonságokat (cikkszám1, cikkszám2, ismertető, stb...). Az ugyvitel_tulajdonsag_id a tulajdonság típusát azonosítja (csz, ismertető, stb.). Jelenleg ~110000 rekorddal.

  Ezekből kéne leválogatni márkanév, terméknév, csz1, csz2, és ismertető alapján (szabad szavas keresővel).

  Az adatbázis tovább fog nőni, akár a többszörösére. MySQL-ről van szó.

• #1539 Vision veterán

  Új Válasz 2013-01-07 15:07:34 #1539

  Ú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

  

  Vision

  veterán

  Egyébként más problémával kapcsolatban - ahol tudom használni a file cache-t - adtatok ötleteket, szóval már ezt is köszönöm.

• #1536 Vision veterán martonx #1533

  Új Válasz 2013-01-07 14:14:57 #1536

  Ú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

  

  Vision

  veterán

  válasz martonx #1533 üzenetére

  Tisztában vagyok a memcache-sel, de úgy vélem, hogy ennél gyorsabb lenne SQL szerveren belül maradni, hiszen a VIEW már úgy lenne összeállítva, hogy a legoptimálisabb legyen lekérdezés-szempontból. Csak azt tartom "pazarlásnak", hogy minden lekérdezésnél frissíti a tartalmát. Kereséshez van szükségem erre, szóval egy 7*20000 soros táblát kéne a cache-ben tartani. Ez sok...

• #1531 Vision veterán martonx #1529

  Új Válasz 2013-01-07 13:11:42 #1531

  Ú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

  

  Vision

  veterán

  válasz martonx #1529 üzenetére

  Nem vagyok eltévedve, és hogyan cache-elsz egy 20.000 soros táblát?

• #1528 Vision veterán

  Új Válasz 2013-01-07 12:28:39 #1528

  Ú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

  

  Vision

  veterán

  Sziasztok!

  Tudtok egy olyan parancsot/függvényt/módszert, amely ugyanúgy működne, mint egy VIEW, de nem frissülne a lekérdezéskor a tartalma, hanem mondjuk csak óránként?

  Illetve mennyivel gyorsabb a lekérdezés egy VIEW-ból (hiszen frissítenie kell a szervernek a tartalmát), mintha én szedném össze az adatokat az összekapcsolt táblákból?

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