Új hozzászólás Aktív témák
-
attis71
tag
válasz
Apollo17hu #2599 üzenetére
Ezt a hibát kapom:
A MySQL mondta: Dokumentáció
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(ORDER BY aru_egysegar DESC) AS sorrend
FROM aruk) aruk
WHERE aru.sorrend < 4
OR' at line 3 -
attis71
tag
válasz
fordfairlane #2602 üzenetére
Ez már működik.
Ezzel adtál pár ötletet.
Nagyon szépen köszönöm.attis71
-
bambano
titán
válasz
Apollo17hu #2601 üzenetére
vitatnám ezt a "nincs túlbonyolítva" dolgot.
te fogod a teljes táblázatot, lekérdezed, raksz mellé egy rank függvényt, minden rekordjára, meg window funkciót, stb. és visszaadod az allekérdezésből a teljes táblázatot. majd a külső lekérdezésben kiválasztod a három legnagyobbat. ehhez felhasználtál egy csomó sql dolgot, amit nem is biztos, hogy minden sql verzió támogat.ehhez képest az enyémben az allekérdezés kiválaszt három rekordot, nincs semmi elektromos csellentyűcske, és három darab rekordot ad vissza a külső lekérdezésnek rendezésre. ráadásul a három legnagyobbat index-szekvenciális kereséssel is megtalálja az adatbáziskezelő, ha van index az adott mezőre, majd a végén összesen három rekordot kezd el sorbarendezni.
futtasd már le mindkét lekérdezést egy táblán, amiben van 20 millió rekord, indexelve...
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bpx
őstag
válasz
bambano #2605 üzenetére
Window function használatával sem fog a 20 millió rekordon végigmenni, ugyanúgy ki tudja választani index mentén az első 3 darabot, és egy ilyen egyszerű példában nincs különbség.
Ugyanakkor én inkább használnám az egyszerűbb módszert. A window function akkor lenne hasznos igazán, ha lenne PARTITION BY, de nincs. Ezen kívül a becsült kardinalitás a window functionnel sokkal pontatlanabb, így sokkal nagyobb az esély egy kevésbé hatékony végrehajtási tervre.
-
bambano
titán
általában a window funkcióknál nem fog, ez igaz, de én nem általában írtam, hanem a konkrét megoldásra.
"egy ilyen egyszerű példában nincs különbség.": ezt az állítást nem ártott volna bebizonyítani, ebben az esetben kiderül, hogy tévedés, és nem készül belőle hozzászólás.
1 millió rekordos teszt adatbázison jól láthatóan gyorsabb a sima subselectes.
test=> explain SELECT t.aru_nev, t.aru_egysegar FROM (SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC) AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Sort (cost=109649.00..110482.34 rows=333333 width=36)
Sort Key: t.aru_egysegar
-> Subquery Scan t (cost=0.00..60836.36 rows=333333 width=36)
Filter: (t.sorrend < 4)
-> WindowAgg (cost=0.00..48336.36 rows=1000000 width=22)
-> Index Scan Backward using i_aru_ar on aruk (cost=0.00..33336.36 rows=1000000 width=22)
(6 rows)test=> explain SELECT * FROM (SELECT aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC LIMIT 3) AS aruk_kivonat ORDER BY aruk_kivonat.aru_egysegar ASC;
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Sort (cost=0.15..0.16 rows=3 width=36)
Sort Key: aruk.aru_egysegar
-> Limit (cost=0.00..0.10 rows=3 width=22)
-> Index Scan Backward using i_aru_ar on aruk (cost=0.00..33336.36 rows=1000000 width=22)
(4 rows)time psql -d test -c 'SELECT t.aru_nev, t.aru_egysegar FROM (SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC) AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar;'
real 0m0.639s
user 0m0.024s
sys 0m0.016stime psql -d test -c 'SELECT * FROM (SELECT aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC LIMIT 3) AS aruk_kivonat ORDER BY aruk_kivonat.aru_egysegar ASC'
real 0m0.032s
user 0m0.024s
sys 0m0.004sha kiveszem a subselecteket és azokat hajtom végre, akkor az első megoldás visszaadja az összes rekordot, a második meg csak hármat.
Fentiek alapján melyik lekérdezés a gyorsabb, optimalizáltabb???
"egy ilyen egyszerű példában nincs különbség.": 19.93750-szeres a különbség egymillió tesztrekordon. A teszt végére még volt üres ram a gépben, tehát nem az döntött, hogy az egyiket vinyóról futtatná, a másikat memóriából, minden teszt teljesen befért a ramba.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bpx
őstag
válasz
bambano #2608 üzenetére
OK, akkor kiegészíteném annyival, hogy Oracle-ben nincs különbség.
SELECT /*+ GATHER_PLAN_STATISTICS */ t.aru_nev, t.aru_egysegar FROM
(SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC)
AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar
Plan hash value: 68470586
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 3 |00:00:00.01 | 4 |
| 1 | SORT ORDER BY | | 1 | 1000K| 3 |00:00:00.01 | 4 |
|* 2 | VIEW | | 1 | 1000K| 3 |00:00:00.01 | 4 |
|* 3 | WINDOW NOSORT STOPKEY | | 1 | 1000K| 4 |00:00:00.01 | 4 |
| 4 | TABLE ACCESS BY INDEX ROWID| ARUK | 1 | 1000K| 5 |00:00:00.01 | 4 |
| 5 | INDEX FULL SCAN DESCENDING| I_ARU_AR | 1 | 1000K| 5 |00:00:00.01 | 3 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("T"."SORREND"<4)
3 - filter(RANK() OVER ( ORDER BY INTERNAL_FUNCTION("ARU_EGYSEGAR") DESC )<4)Az első query-t egy az egyben másoltam, a másodiknál a limitet át kellett írnom, mert az itt nincs.
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC) aruk_kivonat
where rownum < 4 ORDER BY aruk_kivonat.aru_egysegar ASC
Plan hash value: 2883829479
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 3 |00:00:00.01 | 4 |
| 1 | SORT ORDER BY | | 1 | 3 | 3 |00:00:00.01 | 4 |
|* 2 | COUNT STOPKEY | | 1 | | 3 |00:00:00.01 | 4 |
| 3 | VIEW | | 1 | 3 | 3 |00:00:00.01 | 4 |
| 4 | TABLE ACCESS BY INDEX ROWID| ARUK | 1 | 1000K| 3 |00:00:00.01 | 4 |
| 5 | INDEX FULL SCAN DESCENDING| I_ARU_AR | 1 | 3 | 3 |00:00:00.01 | 3 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(ROWNUM<4)0,01 másodperc, 4 darab blokk érintésével megoldotta mindkettő. Egyedüli látványos különbség, hogy az elsőnél mindenhol 1000K a becsült sorok száma.
A 2 query egyébként nem ekvivalens, rank() helyett row_number()-rel lenne az.
-
bambano
titán
persze, hogy nincs különbség, ha a limites átírásoddal pontosan azt a részt teszed tönkre, ami a lényegi különbség a két lekérdezés között.
próbáld ki ezt a két lekérdezést:
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC) aruk_kivonat
where rownum < 4 ORDER BY aruk_kivonat.aru_egysegar ASCés
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk where rownum<4 ORDER BY aru_egysegar DESC) aruk_kivonat
ORDER BY aruk_kivonat.aru_egysegar ASCez csak abban az egy esetben lehet ugyanolyan eredményű, ha az oracle képes olyan mélyen értelmezni a lekérdezést, hogy a külsö selectben használt where rownum<4 klauzát képes bevinni a belső selectbe.
adjon valaki hitelt érdemlő bizonyítékot, hogy az a query, ahol a belső select 1 millió sort ad vissza, ugyanannyi idő alatt lefut és pontosan ugyanannyira optimális, mint az, ahol a belső select csak 3 sort ad vissza.
szerk: illetve futtasd le a subselecteket önmagában és nézd meg a találati halmaz nagyságát.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bpx
őstag
válasz
bambano #2610 üzenetére
Nem tettem tönkre, ezt egyszerűen így kell leírni, mert sajnos nincs LIMIT. A WHERE előbb van, mint az ORDER BY, a másodikban levő subquery azt jelenti, hogy "olvass fel <4 sort a táblából és rendezd", és nem pedig azt, hogy "kérem rendezés után az első <4 sort".
ez csak abban az egy esetben lehet ugyanolyan eredményű, ha az oracle képes olyan mélyen értelmezni a lekérdezést, hogy a külsö selectben használt where rownum<4 klauzát képes bevinni a belső selectbe.
Hasonló, de a sorok számára vonatkozó feltételeket speciálisan kezeli, ezek a végrehajtási tervben megjelenő STOPKEY műveletek, amelyek csak addig futtatják a gyerekeiket, amíg el nem érik a megadott limitet. Tehát valóban az történik, hogy úgy kezd neki, mintha az egészet fel kellene olvasni, de 3 sornál megáll. Az adatbázis az egyéb feltételeket is simán mozgatja szintek között, ha szerinte úgy hatékonyabb, azokra nincs külön művelet.
A subquery-t ha lefuttatom magában, nyilván végigmegy 1 millió sorra, hiszen nem lesz ott a külső szűrés, ami leállítja 3 sornál.
-
drogery
tag
Sziaszok, egy kis segítséget szeretnék kérni. Tud valaki ajánlani, egy jobb ingyenes sql like db szolgáltatót? Annyi kritériumom van, h min 50-100mb tár, sql like query-kkel használható lehessen és legyen java driver. Semmilyen érzékeny adatot nem akarok tárolni rajta, ha az a feltétel, hogy egy index.html ki legyen rakva a tárhelyen az is tökéletes.
-
l_ági
újonc
Sziasztok!
Telepítettem a PL/SQL program próbaverzióját gyakorlás céljából, még kezdő vagyok a témában, úgyhogy előre bocs az amatőr kérdésért...
Már a belépéskor elakadok, ugyanis kéri a felhasználói nevet és jelszót és nem enged be azzal, amit az Oracle regisztrációnál megadtam. Vagy köze sincs ehhez????Előre is köszi!!
Ági -
Louro
őstag
Sziasztok!
A VB után most a PL/SQL Dev-vel ismerkedek. Itt van lehetőség arra, hogy például egy megadott mappából vegye az összes .csv kiterjesztésű fájlt, majd azokból csak bizonyos mezőket hozzak el és ezen felül a fájlnevet betöltsem egy mezőbe?
VB szkripttel ezt megoldottam, de itt nem találok a neten rá vonatkozó cikket.
Segítségetek előre is köszönöm!
Mess with the best / Die like the rest
-
Kommy
veterán
Sziasztok,
van egy kapott view kódom és nem jövök rá mi a gond vele:
CREATE VIEW Example_BestLaps_imola_evoraGtc_p45_Limit_30_Offset_0
AS
WITH BestLapTimeHelper AS (
SELECT MIN(LapTime) AS LapTime, PlayerInSession.PlayerId AS PlayerId, PlayerInSession.CarId AS CarId
FROM Lap JOIN PlayerInSession ON (Lap.PlayerInSessionId=PlayerInSession.PlayerInSessionId)
WHERE
Lap.Valid IN (1,2) AND
Lap.PlayerInSessionId IN (SELECT PlayerInSession.PlayerInSessionId
FROM
PlayerInSession JOIN Session ON (PlayerInSession.SessionId=Session.SessionId)
JOIN Players ON (Players.PlayerId=PlayerInSession.PlayerId)
WHERE Session.TrackId IN (SELECT TrackId FROM Tracks WHERE Track='imola') AND
PlayerInSession.CarId IN (SELECT CarId FROM Cars WHERE Car IN ('lotus_evora_gtc','p4-5_2011'))
)
GROUP BY PlayerInSession.PlayerId,PlayerInSession.CarId
)
SELECT * FROM (
WITH BestLapIds AS (
SELECT MAX(LapTimes.LapId) AS LapId FROM
BestLapTimeHelper JOIN LapTimes ON
(BestLapTimeHelper.LapTime=LapTimes.LapTime AND
BestLapTimeHelper.PlayerId=LapTimes.PlayerId AND
BestLapTimeHelper.CarId=LapTimes.CarId)
GROUP BY LapTimes.LapTime,LapTimes.PlayerId,LapTimes.CarId
ORDER BY LapTimes.LapTime
LIMIT 30
OFFSET 0
)
SELECT Name, LapTimes.LapTime, Valid, LapTimes.Car
FROM BestLapIds JOIN LapTimes ON (BestLapIds.LapId = LapTimes.LapId)
) AS tmpHa kiveszem a GROUP BY PlayerInSession.PlayerId,PlayerInSession.CarId utáni rész akkor lefut különben hibát ad
-
-
Kommy
veterán
-
Apollo17hu
őstag
Akitől kaptad, annál működik?
Nekem nagyon kuszának tűnik az egész, bár én eleve nem JOIN-okat használok.
Egy tippem van: elképzelhető, hogy virtuális nézeten (WITH) belül nem lehet virtuális nézetet létrehozni. Sőt, nem is értem, hogy miért van rá szükség, ha a belső virtuális nézetre egy SELECT * FROM kerül...
-
Apollo17hu
őstag
válasz
Apollo17hu #2623 üzenetére
Mondjuk ez SQLite, de megerősíti, amit írtam:
"The WITH clause cannot be prepended to the second or subsequent SELECT statement of a compound select." -
Kommy
veterán
válasz
Apollo17hu #2623 üzenetére
Sajnos nem tudom megkérdezni, de most már működik miután beimportáltam sqlite-ból postgres-be most már működik megfelelően.
-
PumpkinSeed
addikt
MySQL adatbázist Debian CLI-ből hogy lehet kimenteni?
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
fordfairlane
veterán
-
lakisoft
veterán
válasz
fordfairlane #2628 üzenetére
Ez nem csak az említett környezetre hanem az összes MySQL futtató környezetre alkalmazható.
- Árad -
-
PumpkinSeed
addikt
válasz
fordfairlane #2628 üzenetére
Köszönöm a kisegítést.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
dellfanboy
őstag
van két olyan oszlopom, hogy date_from és date_to
segítsetek már abban, hogy tudok szűrni, hogy 1 adott hónapot kapjak? próbáltam a beetwen-el de nem jött össze (1 id aktív 30 napon keresztül hónap első napjától az utolsóig)
a 2 oszlopban az idő úgy néz ki hogy évhónap órapercmásodperceladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
Ispy
veterán
válasz
dellfanboy #2631 üzenetére
Milyen SQL? Keress valami MONTH, DATEPART szerű függvényt.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
-
supercharley
tag
Sziasztok!
Elég kevéssé értek az SQL-hez, és most bele is akadtam egy problémába.
Erről lenne szó:adattábla
---------
dátum Date8
azonosító Character10
db Numeric 5Az azonosító több dátumon is lehet, illetve van is!
A feladat, hogy minden rekorhoz legyen egy olyan plusz
mező, amelyben az adott azonosítóhoz a db
értékét tartalmazza leösszesítve az adott dátumig
az azonosítókra.
Pl.:adattábla
----------
2014.01.01. 0001 500
2014.01.01. 0002 150
2014.01.02. 0001 80
2014.01.03. 0002 55
2014.01.03. 0001 110erdemény
----------
2014.01.01. 0001 500 500
2014.01.01. 0002 150 150
2014.01.02. 0001 80 580
2014.01.03. 0002 55 205
2014.01.03. 0001 110 690Meg tudná mondani valaki ennek a megoldását?
-
bpx
őstag
válasz
dellfanboy #2633 üzenetére
where
extract(day from date_from) = 1
and extract(day from date_to + 1) = 1
and trunc(date_from, 'MM') = trunc(date_to, 'MM') -
bpx
őstag
válasz
supercharley #2634 üzenetére
select datum, azonosito, sum(darab) over (partition by azonosito order by datum, azonosito range between unbounded preceding and current row) from adattabla
order by datum, azonosito; -
bpx
őstag
válasz
supercharley #2637 üzenetére
akkor itt a buta verzió:
select a1.datum, a1.azonosito, (select sum(a2.darab) from adattabla a2 where a2.azonosito = a1.azonosito and a2.datum <= a1.datum) from adattabla a1
order by a1.datum, a1.azonosito; -
bambano
titán
válasz
dellfanboy #2633 üzenetére
én a két dátum különbségét venném napban és az alapján válogatnék.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
dellfanboy
őstag
közbe gondolkoztam és rájöttem, hogy rosszul tettem fel a kérdést.
mert az első kérdésemmel azon id-kat találom meg akik 1.-jén (date from) aktívak 30.-áig (date to)
de én arra vagyok kiváncsi 1 hónapban hány új id lett/szünt meg
tehát kell képeznem egy februári halmazt és egy márciusit. e kettő különbsége adja meg az növekedést/csökkenést.tehát egy olyanre kellene szűrnöm első sorban hogy a date to cella üres(aktív) a date from pedig adott hónapban töltődött ki. és ha ez megvan, akkor nem is kellene a halmazokkal szórakoznom, hisz megvan az adott hónapban 'született' id-k halmaza. amit keresek.
tehát a date from feb1-feb28 között bármilyen dátum, a date to pedig üres
[ Szerkesztve ]
eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
bpx
őstag
válasz
dellfanboy #2641 üzenetére
pl. február:
where
date_to is null
and trunc(date_from, 'MM') = date'2014-02-01' -
martonx
veterán
válasz
fordfairlane #2648 üzenetére
Én meg lokálisan nem futtatok DB-t, csak felhőből. Így a 4 fejlesztői gépem között a DB-t legalább nem kell szinkronizálgatni.
Én kérek elnézést!
-
#68216320
törölt tag
válasz
fordfairlane #2648 üzenetére
Az a helyzet, hogy én csak a MySQL 5.6-ot letöltöttem és feldobtam a gépre minden konfigolás nélkül, hogy tudjak Apache/Php5-el offline módon weblapot csinálni. Ahogy rákerestem, nincs is my.ini fájlom a gépen. A mysql könyvtárában van egy my-default.ini. Gondolom ebből kellene készíteni.
Eddig ez fel sem tűnt, mert működik minden phpmyadmin alatt.Szolgáltatásoknál be is van állítva a my.ini útvonala, de ott nincs az adott fájl, csak a default.
Átneveztem és ezt tartalmazza:# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the
# *** default location during install, and will be replaced if you
# *** upgrade to a newer version of MySQL.
[mysqld]
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
# These are commonly set, remove the # and set as required.
# basedir = .....
# datadir = .....
# port = .....
# server_id = .....
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLESHogyan érdemes beállítanom? Csak weblap készítéshez kell, nem futtatok olyan webszervert ami terhelné a legcsekélyebb mértékben is.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- RC modell földön, vízen, levegőben
- Jön a Heroes of Might and Magic: Olden Era
- Világegyetem, ősrobbanás, tér-idő
- Diablo IV
- Ukrajnai háború
- Samsung Galaxy S23 Ultra - non plus ultra
- Luck Dragon: Asszociációs játék. :)
- Bezár az Anandtech
- Milyen billentyűzetet vegyek?
- Milyen monitort vegyek?
- További aktív témák...
- Asus ROG Strix Go BT
- Új Ulefone Armor 26 Ultra -120Watt -Ütés Víz és Por Álló Strapa Telefon -Ujjlenyomatos -Endoszkóp
- Philips 24M1N3200ZA Gaming 24" monitor
- Philips Evnia 49M2C8900 (49", OLED, 5120x1440, 240Hz, 10bit, Ívelt 1800R, 0,03ms) Új, Bontatlan!
- Laptopok, Pc-k professzionális karbantartása, tisztítása.
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen