Hirdetés
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Az idei év nagy kérdése: bele lehet férni 8 GB VRAM-ba?
- LG LCD és LED TV-k
- Az AMD szerint Radeonokból nem lesz hiány
- 30 TB fölé ugrott a Seagate HAMR merevlemezcsaládja
- Azonnali notebookos kérdések órája
- Nem elég a RAM-ok, NAND-ok és VGA-k áremelkedése
- AMD Navi Radeon™ RX 9xxx sorozat
- CES 2026: igazi mindenes a Lenovo legújabb, 4K-s QD-OLED monitora
- Milyen billentyűzetet vegyek?
Új hozzászólás Aktív témák
-
Drizzt
nagyúr
válasz
Orionk
#10365
üzenetére
Egyfelől van SQL topic, ez oda jobban illene.
Másfelől:
- Indexeket kell használni. Azt az oszlopot kell indexelni, ami a where feltételben szerepel elsősorban. Ebből is elsősorban azok lesznek gyorsak, amikor konkrét értékre vonatkozik a feltétel, vagy arra, hogy egy érték egy tartományban van-e. Ha több oszlop is van a keresésben, lehet kompozit indexeket definiálni. Ha pl.: van a,b,c oszlopra egy indexed, azt az olyan feltételekre lehet használni, ahol vagy csak a-ra, vagy a-ra és b-re, vagy a-ra, b-re, s c-re van megszorító feltétel megadva. Az index gyorsítja a keresést, de lassítja a beszúrást, törlést. Ezen kívül még fontos, hogy ha csak az indexben szereplő dolgokat fogsz kikeresni a select-tel, akkor az szinte biztosan csak memóriában fog történni, de a többi mező lekérdezéséhez már lehet a diszkhez kell fordulni, ami lassítani fog erősen. Másik megfontolás a select oszlopok számánál, hogy minden extra oszlop megnöveli a visszaadott adathalmaz méretét, emiatt ha a sávszélesség probléma az adatbázis és az alkalmazás szerver között, akkor ronthat a sebességen. Erre szoktak DTO-kat használni(olyan objektum, ami csak a teljese tábla oszlopainak egy részét tartalmazza. Azt, amire éppen minimálisan szükség van az adott probléma megoldásához.).
- Nem árt megnézni azt sem, hogy a lekérdezés tényleg fogja-e használni az elkészített indexet. Erre általában adatbázisonként különbözik, hogy milyen paranccsal, de le lehet kérdezni, hogy mi lesz a query excution plan. Abból kiderül, hogy fog-e használni indexet, vagy nem. Illetve melyiket. A kritikus lekérdezésekre szerintem mindig ellenőrizni kell.
- Ha gyakran használ az ember joint, akkor érdemes lehet elgondolkodni a joinolt tábla foreign key-ként használt oszlopának indexelésén. Ez nagyban felgyorsíthatja a join-ok sebességét.
- Ha a beszúrás és a törlés is nagyon gyakran történik meg és a tábla nagy, akkor érdemes lehet particionálni a táblát több részre. Mondjuk ha neveket tárolsz, akkor az egyik tabla csak a-b, a másik c-d, ... kezdetű neveket tartalmazza. Viszont ilyenkor pl. nehéz lesz jó foreign keyeket definálni a nevekre, s sok egyéb komplikáció előjöhet. Ha ilyen jellegű a probléma, akkor lehet érdemesebb valamilyen noSQL db-t választani RDBMS helyett.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Kerékpárosok, bringások ide!
- OpenWRT topic
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Samsung Galaxy Felhasználók OFF topicja
- Sorozatok
- Debrecen és környéke adok-veszek-beszélgetek
- vrob: Az utolsó DOS játékok 1996 - 1997-ben, egy korszak lezárul
- Asztalos klub
- Milyen autót vegyek?
- További aktív témák...
- Eladó Asus TUF FX506IU FHD IPS Ryzen 7 magyar bill 1 hét gar
- Vadiúj AMD konfig összeszerelésre vár .
- új iPhone 17 Pro 256GB silver ezüst független Apple 1 év garancia
- új iPhone 17 Pro 256GB deep blue mélykék független Apple 1 év garancia
- új iPhone Air 256GB space black asztrofekete független Apple 1 év garancia
- Kuriózum: Ozark Trail (amerikai) fejlámpa 600 lumen
- BESZÁMÍTÁS! ASUS ROG Crosshair VIII Extreme alaplap garanciával hibátlan működéssel
- Általános igazgatóhelyettes tábla üvegből eladó
- Újszerű Acer Aspire A515 - 15.6"FHD IPS - i5-1335U - 16GB - 512GB SSD - Win11
- Samsung Galaxy S20 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest


