Ind til faktisk lige nu, har min aften gået med at optimere en side i SQL, det har vist sig at jeg kunne ud fra at lave nogle ting om i programmeringen og benytte INNER JOINs plus subselect i MySQL koden, så har jeg faktisk redusert antal querys til serveren enormt.
Det skal siges her er der tale om en side hvor du kan se 1 galleri billede, gå frem til næste billede eller tilbage til det sidste billede, udlæse brugerne kommentare og lave lidt urls.
Før kostet dette over 35 Querys, med lidt SQL optimeren er jeg nu helt nede på 9 stk, har enndu ikke gennem gået om jeg kan få det yderlige ned, kan jeg det vil det jo være super, men fra 35 til 9 er også en form for tal ;)
her er der lige en dummy kode af de SQL kode jeg har skrevet for at optimer allermest.
[code]SELECT
i.userid AS userid,
i.albumid AS albumid,
i.name AS filename,
u.uploadid AS uploadid,
i.id AS id,
(
SELECT
im.id AS img_name
FROM
jf_image im
WHERE
im.id > i.id AND
im.userid = u.id
LIMIT 1
) AS image_back,
(
SELECT
im.id AS img_name
FROM
jf_image im
WHERE
im.id < i.id AND
im.userid = u.id
ORDER BY
im.id DESC
LIMIT 1
) AS image_next
FROM
". DB_PREFIX ."image i INNER JOIN ". DB_PREFIX ."user u ON i.userid = u.id
WHERE
i.albumid = '". $albumid ."' AND
i.id = '". $pictureid ."'
ORDER BY
i.id DESC[/code]
Jeg håber det kan give jer der ude et indblink i hvor vigtig det enligt er at optimer sin SQL og benytte INNER JOINs + Subselects
Oftest er det vigtigt at kigge på hvor lang tid queries tager og ikke hvor mange der er. Hvis dine 35 queries tager 1 sekund pr stk bruger databasen 35 sekunder, hvis dine nyligt “optimerede” queries derimod tager 4 sekunder hver bruger databasen nu 36 sekunder og så har du ikke vundet noget (udover tid der bruges på at hente connections fra pooling). Istedet for at fokusere på antal skal du fokusere på tid.
Tid og antal høre tit og ofte sammen, hvis der bliver lavet en fryglig masse querys som ikke er nødvendigt i et SQL kald, der næst er der naturligvis også en masse SQL man skal kikke nærmere på eks. INNER JOINs er langt hurtigere end normale WHERE t1.f1 = t2.f2 fra SQLen, :)
Tid og antal hører desværre ikke sammen så tit som man tror. Det afhænger af eksekveringsplanen på databasen så du skal starte her for at finde ud af om du rent faktisk optimerer eller skyder dig selv i foden. Derudover er det også ofte en god ide at kigge på om ens plan bruger de rigtige indexes før man begynder at skrive koden om, eller ihvertfald tager det med i sine overvejelser