Hirdetés
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Milyen CPU léghűtést vegyek?
- Vezetékes FÜLhallgatók
- SSD kibeszélő
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- TCL LCD és LED TV-k
- SONY LCD és LED TV-k
- Milyen videókártyát?
Ú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?:))
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Jövedelem
- GoodSpeed: Márkaváltás sok-sok év után
- 4G-s verzióban is érkezik a Redmi Note 15 Pro
- Óra topik
- Milyen CPU léghűtést vegyek?
- Vezetékes FÜLhallgatók
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- Xiaomi 15T - reakció nélkül nincs egyensúly
- További aktív témák...
- ARCTIC Liquid Freezer III 360 A-RGB Processzor vízhűtő
- Phanteks Eclipse P600S Black Számítógép ház
- Corsair 32GB KIT DDR5 6000MHz CL30 Vengeance RGB Grey AMD EXPO / XMP
- Iphone 16 PRO 256GB Titanium BLACK - Garanciás - Akku: 94%
- Esport Gaming PC (Intel i5-9400F, 32GB RAM, RTX 2060, 500GB SSD) Eredeti Windows11 Pro
- Apple iPad 11 (A16) 128GB Wifi Silver 1ÉV Bontatlan
- Xiaomi Mi 10T Lite 128GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 14 Pro 128GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, 100% Akkumulátor
- 164 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4090
- BESZÁMÍTÁS! MSI Z690 i9 14900K 32GB DDR5 1TB SSD RTX 3090 OC 24GB Zalman Z1 PLUS Seasonic 750W
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi


