PHP.EE FOORUM   
Nimi:   Pass:   Mäleta mind! 
   Teemad | php.ee esilehele | registreeri | Märgi kõik teemad loetuks | #php.ee Skype vestlus | RSS
UUS TEEMA  OTSI  Lehekülgi: 1
Inner join päringu optimeerimine
Postitaja: puuslik 2018-05-01 21:13:44
Tere!
Palun tarkadelt nõu.

Antud päringu kestvus on 13 sekundit otse serveris. tabelist1 tuleb antud päringu järgi 3057 rida(grupeerimata), mis seotakse tabeli2 ridade väärtustega ja grupeeritakse kuna on vaja kätte saada ainult erinevad uid-d. (grupeeritult 260 rida). Kindlasti võib ka miski muu faktor seda päringut aeglustada, järsku saaks mõne mõtte lendu lasta. Olen hobikorras koodi kirjutaja.


PHP kood:
 

SELECT a
.kuupa.kuup_2a.info1a.info12a.info13a.info14,
FROM tabel esimene AS a
INNER JOIN tabel teine 
AS b ON a.uid b.uid
WHERE DATE_FORMAT
liitunud_aeg'%Y-%m-%d' ) <= '2018-03-31'
AND (
DATE_FORMATkuup'%Y-%m-%d' ) > '2018-03-31'
OR (
DATE_FORMATkuup'%Y-%m-%d' ) =0  ))
AND 
data2 =2 GROUP BY uid ASC

RE: Inner join päringu optimeerimine
Postitaja: blaa 2018-05-01 22:25:05
Lisa tabelite struktuur ja indeksid ka palun.
Arvan, et mõni oluline indeks on puudu.
Pane tingimus data2=2 kõige esimeseks.
DATE_FORMAT( kuup, '%Y-%m-%d' ) = 0, see on küsimusi tekitav. Mis sul andmebaasis on, mis sellele tingimusele vastab? 0000-00-00? Võibolla oleks selle asemel parem veeru määrangusse null ja päringusse "kuup is null".
RE: Inner join päringu optimeerimine
Postitaja: puuslik 2018-05-02 13:23:41
Tänud! Kas blaa kasutajaga saab ka kuidagi maili teel ühendust?
RE: Inner join päringu optimeerimine
Postitaja: puuslik 2018-05-02 23:52:13
Sellest mõttest, mille sain siin oli väga palju abi ja sain asja jooksma. Tänud vastajale :)
RE: Inner join päringu optimeerimine
Postitaja: koodi_näriv_mardikas 2018-05-31 11:18:08
TSITEERITUD:

Sellest mõttest, mille sain siin oli väga palju abi ja sain asja jooksma. Tänud vastajale :)


Teie lahenduses on räige viga. Te loete SQL-päringuga
kõigepealt kogu andmebaasi poolt vastusena
saadetud andmed enda veebitarkvara poolt
allokeeritud mällu(mäassiivid, paisktabelid, muud muutujad),
aga kui päringu vastus peaks olema mitme GiB jagu
andmeid, siis parimal juhul on Teie rakendus
tigu-aeglane, halvimal juhul jookseb Teie rakendus
kokku, sest mälu saab otsa. Lisavõimalusena on
variant, et neid mitme GiB jagu andmeid tagastavaid
päringuid sooritavad mitu veebitarkvara kasutajat,
mitu lõime, paralleelselt, igaüks neist selleks
mälu allokeerides ja andmebaasi ning veebitarkvara
vahel andmeid vahetades/kopeerides. Sellisel
juul võib pudelikaelaks saada isegi kõvaketta
lugemiskiirus, sest andmebaasimootorid salvestavad oma
andmetest enamust enamasti kõvakettal või
RAID-massiivis.

Lahenduseks on, kui täiendate oma SQL-päringut
lisapiiranguga, et andmebaasimootor tagastab
maksimaalselt N andmerida.

https://www.w3schools.com/php/php_mysql_select_limit.asp

Pärast selle muudatuse kasutuselevõttu tuleb ülejäänud
koodi "äriloogika" osa samuti üle vaadata, sest
need N andmerida ei pruugi sisaldada kõike, mida te
andmetest saada soovite. Näiteks aritmeetilist
keskmist arvutades tuleb N andmerea pealt arvutades
vale vastus kui päring tagastaks ilma piiranguta
N+M andmerida. Samas, kui piirang on N andmerida ja
piirangute vaba päring tagastaks maksimaalselt N
andmerida, sest rohkem andmeid päringule ei vasta,
siis saab päringu põhjal naiivselt aritmeetilist
keskmist arvutades õige vastuse. Seega, algoritm
tuleb üle vaadata, vaid testimisest, testide läbimisest,
ei piisa.

RE: Inner join päringu optimeerimine
Postitaja: gaal 2018-07-11 19:56:53
Jah, tavaliselt on WHERE otsingu tingimuste juures kõige problemaatilisem OR operaatori kasutamine, sellega tuleb alati ettevaatlik olla, muidu valmistab väljastavate ridade hulk tihtilugu ebameeldiva üllatuse.

Leheküljed: 1

©2002-2013 Martin Rebane & PHP.ee kaasautorid
  0.44893693924