Ú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?:))
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- Kertészet, mezőgazdaság topik
- Samsung kuponkunyeráló
- Gurulunk, WAZE?!
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- PlayStation 5
- Amlogic S905, S912 processzoros készülékek
- Heroes of the Storm
- Borderlands 4
- A fociról könnyedén, egy baráti társaságban
- További aktív témák...
- DELL PowerEdge R630 rack szerver - 2xE5-2650v3 (20 mag / 40 szál, 2.3/3.0GHz), 32GB RAM, 66921Ft+ÁFA
- -ÚJ- 2x8GB 3600MHz Apacer NOX hűtőbordás DDR4 kitek! GAR/SZÁMLA (a Te nevedre kiállítva)!
- Kingston HyperX Fury Beast 2x8GB 3200MHz DDR4 kit / Beszámítás OK!
- G.SKILL Ripjaws V 2x4GB 3000MHz DDR4 kit
- Dell Latitude 7480 használt laptop eladó
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 5050 8GB GAMER PC termékbeszámítással
- KÉSZLETKISÖPRÉSI ULTRAAKCIÓ! - MacBook Air M4 16GB 512GB Garancia!
- LG 77C4 - 77" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - 1000 Nits
- Bomba ár! HP ProBook 430 G1 - i3-4GEN I 4GB I 500GB I HDMI I 13,3" HD I Cam I W10 I Garancia!
- Apple iPhone 16 Pro 128 GB Natural Titanium 2027.01.28-ig ISTYLE Garancia Beszámítás Házhozszállítás
Állásajánlatok
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest

