Avaleht
uus teema   vasta Tarkvara »  Programmeerimine »  MySQL-i päringut efektiivsemaks märgi kõik teemad loetuks
märgi mitteloetuks
vaata eelmist teemat :: vaata järgmist teemat
Hinnavaatlus :: Foorum :: Uudised :: Ärifoorumid :: HV F1 ennustusvõistlus :: Pangalink :: Telekavad :: HV toote otsing
autor
sõnum Saada viide sõbrale.  :: Teata moderaatorile teata moderaatorile
otsing:  
mikk36
HV Guru
mikk36

liitunud: 21.02.2004
sõnum 27.01.2014 23:24:31 MySQL-i päringut efektiivsemaks vasta tsitaadiga
Hei,

Kerge mure ühe päringuga, ehk on siin keegi, kes oskab vihjata või abi anda et kuidas teist kiiremaks saada?

sql:
  1. SELECT
  2. stats.date,
  3. stats.acceptedMegahashesPerSecond,
  4. stats.rejectedMegahashesPerSecond,
  5. AVG(stats2.acceptedMegahashesPerSecond) AS acceptedMegahashesPerSecond5HourAverage,
  6. AVG(stats2.rejectedMegahashesPerSecond) AS rejectedMegahashesPerSecond5HourAverage
  7. FROM
  8. stats
  9. LEFT OUTER JOIN stats stats2
  10. ON stats2.date BETWEEN DATE_ADD(stats.date, INTERVAL -5 HOUR) AND stats.date
  11. WHERE
  12. stats.address = "19hKwU5NmGRtzLdz8Xd2QbPn7EMzQ26m25" AND
  13. stats2.address = "19hKwU5NmGRtzLdz8Xd2QbPn7EMzQ26m25"
  14. GROUP BY
  15. stats.date
  16. ORDER BY
  17. stats.date ASC

Kommentaarid: 85 loe/lisa Kasutajad arvavad:  :: 0 :: 2 :: 78
tagasi üles
vaata kasutaja infot saada privaatsõnum
Redikate
HV veteran
Redikate

liitunud: 30.12.2005
sõnum 27.01.2014 23:38:41 vasta tsitaadiga
indexeeri stats2.date ära ja ka stats.date. Ühesõnaga kõik väljad mida sa jonimiseks kasutad.

http://dev.mysql.com/doc/refman/5.0/en/create-index.html

E: Ma pole kindel kas DATETIME / TIME / DATE columne saab indexeerida, kuid worth a shot.
_________________
http://nodejs.org/
"I'm also a person. Programming is just one thing I do."
Kommentaarid: 34 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 33
tagasi üles
vaata kasutaja infot saada privaatsõnum
mikk36
HV Guru
mikk36

liitunud: 21.02.2004
sõnum 27.01.2014 23:59:20 vasta tsitaadiga
Redikate, vaata 9. rida.
Kommentaarid: 85 loe/lisa Kasutajad arvavad:  :: 0 :: 2 :: 78
tagasi üles
vaata kasutaja infot saada privaatsõnum
Renka
HV Guru
Renka

liitunud: 01.04.2002
sõnum 28.01.2014 00:58:35 vasta tsitaadiga
mikk36, kaks eraldi päringut ei oleks mõistlikum? Või siis UNIONiga ühte kokku pannes?

Kui ma õigesti mäletan siis OUTER join puhul kasutatakse temp tabelit igal juhul.
_________________
There is no place like 127.0.0.1
Kommentaarid: 71 loe/lisa Kasutajad arvavad:  :: 2 :: 1 :: 61
tagasi üles
vaata kasutaja infot saada privaatsõnum mine selle kasutaja kodulehele
Redikate
HV veteran
Redikate

liitunud: 30.12.2005
sõnum 28.01.2014 02:09:09 vasta tsitaadiga
mikk36 kirjutas:
Redikate, vaata 9. rida.


nvm, sain.
_________________
http://nodejs.org/
"I'm also a person. Programming is just one thing I do."
Kommentaarid: 34 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 33
tagasi üles
vaata kasutaja infot saada privaatsõnum
RassK
HV Guru
RassK

liitunud: 17.01.2007



Autoriseeritud ID-kaardiga
sõnum 28.01.2014 02:42:00 vasta tsitaadiga
Protsentuaalset parandust välja pakkuda ei oska... aga vaata, et tmp tabeli mällu kirjutamisel confis määratud mälu täis ei saa, et ta seda kettale ei kirjutaks.
Kommentaarid: 116 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 101
tagasi üles
vaata kasutaja infot saada privaatsõnum
napoleon
Unknown virus
napoleon

liitunud: 08.12.2008



Autoriseeritud ID-kaardiga
sõnum 28.01.2014 12:22:30 vasta tsitaadiga
Lihtsalt mõte - hetkel tehakse join ära ja siis hakatakse where osa närima. Kui see pole kokkusattumus, et antud näites stats.address ja stats2.address samad on, siis mina teeks joini nii:
LEFT OUTER JOIN stats stats2
ON stats.address = stats2.address and stats2.date BETWEEN DATE_ADD(stats.date, INTERVAL -5 HOUR) AND stats.date

ja WHERE osas võrdleks ainult stats.address välja

Lisaks.... antud näite puhul tundub mulle, et pole võimalust, et stats2-st midagi ei leita, seega LEFT JOIN pole otseselt vajalik. Proovi LEFT JOIN asemel INNER JOINi kasutada, INNER JOIN on kiirem.

EDIT ühesõnaga soovitaks proovida sellist päringut:
sql:
  1.  
  2.     SELECT
  3.     stats.date,
  4.     stats.acceptedMegahashesPerSecond,
  5.     stats.rejectedMegahashesPerSecond,
  6.     AVG(stats2.acceptedMegahashesPerSecond) AS acceptedMegahashesPerSecond5HourAverage,
  7.     AVG(stats2.rejectedMegahashesPerSecond) AS rejectedMegahashesPerSecond5HourAverage
  8.     FROM
  9.     stats
  10.     INNER JOIN stats stats2
  11.     ON stats.address = stats2.address AND stats2.date BETWEEN DATE_ADD(stats.date, INTERVAL -5 HOUR) AND stats.date
  12.     WHERE
  13.     stats.address = "19hKwU5NmGRtzLdz8Xd2QbPn7EMzQ26m25"
  14.     GROUP BY
  15.     stats.date
  16.     ORDER BY
  17.     stats.date ASC
  18.  
Kommentaarid: 77 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 60
tagasi üles
vaata kasutaja infot saada privaatsõnum
mikk36
HV Guru
mikk36

liitunud: 21.02.2004
sõnum 28.01.2014 13:40:48 vasta tsitaadiga
/tmp on niigi mapitud juba tmpfs'ina RAMis.

napoleon, kiirem see päring kuidagi pole kahjuks, aeglane osa on endiselt temp tabelisse kopeerimine.
Kommentaarid: 85 loe/lisa Kasutajad arvavad:  :: 0 :: 2 :: 78
tagasi üles
vaata kasutaja infot saada privaatsõnum
andresv
HV kasutaja

liitunud: 06.12.2004



Autoriseeritud ID-kaardiga
sõnum 29.01.2014 09:43:41 vasta tsitaadiga
tmp table kasutatakse arvatavasti filesort-i jaoks. Ja seda siis kui tagastatud tulemus mida vaja sorteerida ei mahu mällu.

äkki abi siit http://stackoverflow.com/questions/12148943/mysql-performance-slow-using-filesort

Seal ka mingi vihje, et kui sorteerimiiseks ei õnnestu indekseid kasutada siis kasutatakse filesort-i.

Ehs sis võid vaadata kas sorteerimata on tulemus kiirem.
Kommentaarid: 5 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 5
tagasi üles
vaata kasutaja infot saada privaatsõnum
mikk36
HV Guru
mikk36

liitunud: 21.02.2004
sõnum 29.01.2014 20:14:06 vasta tsitaadiga
Sorteerimine ei mõjutanud üldse tulemust.
Jäin praegu sellise päringu peale:
sql:
  1. SELECT
  2. s1.date,
  3. s1.acceptedMegahashesPerSecond,
  4. s1.rejectedMegahashesPerSecond,
  5. AVG(s2.acceptedMegahashesPerSecond) AS acceptedMegahashesPerSecond5HourAverage,
  6. AVG(s2.rejectedMegahashesPerSecond) AS rejectedMegahashesPerSecond5HourAverage
  7. FROM
  8. (
  9.   SELECT stats.date, stats.acceptedMegahashesPerSecond, stats.rejectedMegahashesPerSecond
  10.   FROM stats
  11.   WHERE stats.address = "19hKwU5NmGRtzLdz8Xd2QbPn7EMzQ26m25"
  12. ) AS s1,
  13. (
  14.   SELECT stats.date, stats.acceptedMegahashesPerSecond, stats.rejectedMegahashesPerSecond
  15.   FROM stats
  16.   WHERE stats.address = "19hKwU5NmGRtzLdz8Xd2QbPn7EMzQ26m25"
  17. ) AS s2
  18. WHERE s2.date BETWEEN DATE_ADD(s1.date, INTERVAL -5 HOUR) AND s1.date
  19. GROUP BY s1.date
  20. ORDER BY s1.date ASC
Eriti kiireks muutub see päring siis, kui soovida väljavõtet vaid viimase viie päeva kohta näiteks:
sql:
  1. SELECT
  2. s1.date,
  3. s1.acceptedMegahashesPerSecond,
  4. s1.rejectedMegahashesPerSecond,
  5. AVG(s2.acceptedMegahashesPerSecond) AS acceptedMegahashesPerSecond5HourAverage,
  6. AVG(s2.rejectedMegahashesPerSecond) AS rejectedMegahashesPerSecond5HourAverage
  7. FROM
  8. (
  9.   SELECT stats.date, stats.acceptedMegahashesPerSecond, stats.rejectedMegahashesPerSecond
  10.   FROM stats
  11.   WHERE stats.address = "19hKwU5NmGRtzLdz8Xd2QbPn7EMzQ26m25"
  12.   AND stats.date > DATE_ADD(NOW(), INTERVAL -5 DAY)
  13. ) AS s1,
  14. (
  15.   SELECT stats.date, stats.acceptedMegahashesPerSecond, stats.rejectedMegahashesPerSecond
  16.   FROM stats
  17.   WHERE stats.address = "19hKwU5NmGRtzLdz8Xd2QbPn7EMzQ26m25"
  18.   AND stats.date > DATE_ADD(DATE_ADD(NOW(), INTERVAL -5 DAY), INTERVAL -5 HOUR)
  19. ) AS s2
  20. WHERE s2.date BETWEEN DATE_ADD(s1.date, INTERVAL -5 HOUR) AND s1.date
  21. GROUP BY s1.date
  22. ORDER BY s1.date ASC
Kommentaarid: 85 loe/lisa Kasutajad arvavad:  :: 0 :: 2 :: 78
tagasi üles
vaata kasutaja infot saada privaatsõnum
Le Inc
HV Guru
Le Inc

liitunud: 06.09.2002



Autoriseeritud ID-kaardiga
sõnum 15.02.2014 22:34:02 vasta tsitaadiga
Lihtsalt remargina - elu näitab et kuupäeva järgi sorteerimine ongi aeglane. Mul on üks ~3 mil reaga tabel, sorteerides kuupäeva järgi on esimese 10 kuvamine ~3-4 sek, samas sorteerides aadressi järgi ~0,5..0,7 s. Oracle.

Vahepeal kui päring väga aeglaseks läheb, siis aitab tabeli analüüsimine (tabel kasvab kiiresti).
Kommentaarid: 56 loe/lisa Kasutajad arvavad:  :: 0 :: 0 :: 54
tagasi üles
vaata kasutaja infot saada privaatsõnum
näita postitusi alates eelmisest:   
uus teema   vasta Tarkvara »  Programmeerimine »  MySQL-i päringut efektiivsemaks
[vaata eelmist teemat] [vaata järgmist teemat]
 lisa lemmikuks
näita foorumit:  
 ignoreeri teemat 
sa ei või postitada uusi teemasid siia foorumisse
sa ei või vastata selle foorumi teemadele
sa ei või muuta oma postitusi selles foorumis
sa ei või kustutada oma postitusi selles foorumis
sa ei või vastata küsitlustele selles foorumis
sa ei saa lisada manuseid selles foorumis
sa võid manuseid alla laadida selles foorumis



Hinnavaatlus ei vastuta foorumis tehtud postituste eest.