[PHP/MySQL] Trage query

[vorlox]

Beste,

Ik heb een klein probleempje met een query

ik heb drie tabellen.
produkten
artikelen
lngcntart

in produkten staan +/- 800 records
in artikelen staan 11.000 records met NIET taalafhankelijke velden
en in lngcntart staan 66.0000 records met daarin voor 6 talen de taalafhankelijke velden van het artikel


Nu heb ik een stukje code wat een tabelletje genereerd met daarin de waardes van de query

PHP:

<?
function GetArtikcle($prdID,$setlang)
{
echo "<table border=1><tr>";
$viewquery = "artikelen.artnummer,lngcntart.artikelomschrijving ";
$SQL = " SELECT "; 
$SQL .= " artikelen.artID,  ";
$SQL .= " $viewquery,  ";
$SQL .= " lngcntart.intern, ";
$SQL .= " lngcntart.extern  ";
$SQL .= " from artikelen,lngcntart ";
$SQL .= " WHERE artikelen.artID = lngcntart.itemID  ";
$SQL .= " AND lngcntart.langID = '$setlang'  ";
$SQL .= " AND artikelen.prdID = '$prdID'  ";
$SQL .= " $EXTRASQL ORDER BY artikelen.sortering ASC";

echo "<HR>$SQL<HR>";
$result_art = mysql_query("$SQL");              
while($row_test = mysql_fetch_array($result_art))
{
   foreach($row_test as $value)
   {
      echo "<td>$value</td>";
   }
} //End while($row_test = mysql_fetch_array($result_art)
echo "</tr></table>";
}//End 
?>

Het probleem is dat deze query +/- 1 a 2 sec duurt op een PIII 667 - 512MB en 1 concurrent user...(moi)

Nou dat vind ik nogal traag zoals je kunt begrijpen

Een oplossing zou natuurlijk zijn om het tabelletje hard te parsen naar een bestand als er een update in voorkomt.

Is er een ander mogelijkheid om sit stukje code te optimaliseren?

Een suggestie zou welkom zijn

[ Voor 11% gewijzigd door vorlox op 14-05-2003 14:17 ]

[js303]

OK 2 tips die ik je meteen al kan geven, want ik zat een poosje met een soortgelijk probleem:

1. Ipv de specifieke velden te selecteren gewoon SELECT * doen, dat gaat bij mij iig veel sneller.
2. Indexeer van de velden die in je WHERE clause staan, zoals artID, langID en prdID. En dan indexeren per veld of per groep velden als ze in 1 tabel voorkomen, gewoon op INDEX zonder waarde werkt bij mij goed. Met phpMyAdmin gaat dit heel makkelijk.

Probeer dit en de kans is groot dat je query 50x zo snel gaat.

[ Voor 22% gewijzigd door js303 op 14-05-2003 14:22 ]

[sjroorda]

Je moet juist niet SELECT * doen; dit gaat juist ten koste van de snelheid! Zoveel mogelijk de kolommen specificeren.

En verder zie ik zo 1-2-3 niet waar je wat kan verbeteren. Begin eerst eens met de indices op de kolommen zetten, zoals js303 zegt, dat scheelt vaak al erg veel.

Verder blijf je natuurlijk met een zeer grote DB zitten, daar heb je dus altijd wat problemen mee met de snelheid!

[ Voor 54% gewijzigd door sjroorda op 14-05-2003 14:23 ]

[Brakkie]

1. Ipv de specifieke velden te selecteren gewoon SELECT * doen, dat gaat bij mij iig veel sneller.

Lijkt me onzin. Als een query meer moet selecteren en teruggeven wordt ie langzamer lijkt me.

Zo groot is z'n db trouwens niet.

ASC of DESC maakt ook nog uit. Een van de twee is sneller weet ff niet meer welke.

[ Voor 23% gewijzigd door Brakkie op 14-05-2003 14:27 ]

[Verwijderd]

Goed je DB indexeren is het belangrijkste lijkt me. In de P&W FAQ - SQL staat een leuk stukje over hoe je het beste indexen kunt zetten.

[js303]

Je moet juist niet SELECT * doen; dit gaat juist ten koste van de snelheid! Zoveel mogelijk de kolommen specificeren.

ik dacht dat ook maar als ik dat dus doe, en in mijn geval gaat het om 15 velden, dan zit ik gemiddeld op de 0.18 seconden terwijl als ik gewoon alle velden * selecteer dan zit ik meestal onder 0.10 seconden! raar maar waar.

[whoami]

SELECT * is idd trager dan SELECT veld, veld, .... maar dat zal niet het grootste verschil uitmaken.

Je zult goede indexen moeten leggen op je tabel. De velden waar je op filtert, sorteerd en joined kunnen in aanmerking komen voor een index.

[[ash]]

Kan je geen gebruik maken van 'join' om je tabellen te koppelen ipv één select statement die alle tabellen moet doorzoeken ?

Ze ook: http://www.mysql.com/doc/en/JOIN.html

[js303]

baseren jullie je mening rond de * op theorien of feitelijke metingen?

[vorlox]

He bedankt voor de reacties.

Hmm, indexeren van de velden zou inderdaad kunnen helpen. (Ga ik nat even mee stoeien)
Een select * werkt in dit geval redelijk vertragend. (tried it)

Ik denk zelf dat hard wegscrijven naar een bestand ('S Nachts of per update ofzo een beter idee is) De data wijzigt niet zoveel dat het echt veel uitmaakt of het live is.

Hmm rottig zo'n probleempje

Ik heb ook MSSQL enterprise edition draaien op die bak
ik zou eens kunnen proberen een conversie te doen van die drie tabllen en te kijken of MSSQL er meer van bakt (Denk ut niet trouwens).

Er is wel nog een klein puntje wat ik vergeten was te vermelden.
Die PIII 667 draait op WinXP PRO 2002 edition....dus geen linux

Dit is dan ook de testserver
De produktie server is een RH 7.2 linuxdoos met 2x Xeon 2Ghz en 1,5MB RAM dus en daar merk ik weinig...??

Alleen is het natuurlijk wel zo dat daar +/- 100 gebruikers op zitten.

AAARgh dilemma

[vorlox]

Kan je geen gebruik maken van 'join' om je tabellen te koppelen ipv één select statement die alle tabellen moet doorzoeken ?

Ze ook: http://www.mysql.com/doc/en/JOIN.html

Uhh ... volgens mij doe ik dat ook


zie SQL .= " artikelen.artID=lngcntart.itemID ";

baseren jullie je mening rond de * op theorien of feitelijke metingen?

gevoelsmeting + php script meting.....geen benchmark

[ Voor 37% gewijzigd door vorlox op 14-05-2003 14:36 ]

[whoami]

js303 schreef op 14 May 2003 @ 14:30:
baseren jullie je mening rond de * op theorien of feitelijke metingen?

Feitelijke meningen.
Er dwaalt hier wel ergens een topic rond waarin dat gebenchemarked werd (in MySQL dacht ik).

Ook op de site www.sql-server-performance.com staat dat het gebruik van * trager is in SQL Server dan het specifieren van de velden zelf. (Bijkomend nadeel van het gebruik van * is ook dat er in de meeste gevallen meer data gereturned wordt dan nodig is)

[ Voor 35% gewijzigd door whoami op 14-05-2003 14:36 ]

[js303]

ok

[whoami]

vorlox schreef op 14 May 2003 @ 14:32:
He bedankt voor de reacties.

Hmm, indexeren van de velden zou inderdaad kunnen helpen. (Ga ik nat even mee stoeien)

Zou kunnen? Probeer het uit en sta versteld van de resultaten.
Door gebruik te maken van indexen kan het DBMS veel efficiënter de rows ophalen. Als je geen indexen gebruikt moet het DBMS een table scan doen, wat dus wel zeeeeeer vertragend werkt.

Ik denk zelf dat hard wegscrijven naar een bestand ('S Nachts of per update ofzo een beter idee is) De data wijzigt niet zoveel dat het echt veel uitmaakt of het live is.

Waarom zou dat een beter idee zijn dan gebruik te maken van een index?
Ik zie daar geen heil in.

Ik heb ook MSSQL enterprise edition draaien op die bak
ik zou eens kunnen proberen een conversie te doen van die drie tabllen en te kijken of MSSQL er meer van bakt (Denk ut niet trouwens).

Als je ook daar geen indexen legt, zal het niet veel uitmaken.

[[ash]]

vorlox schreef op 14 mei 2003 @ 14:34:
Uhh ... volgens mij doe ik dat ook

zie SQL .= " artikelen.artID=lngcntart.itemID ";

Hmm, maakt MySQL er zelf JOINS van Zie namelijk geen JOIN in jouw syntax staan... en waarom is de join syntax er dan eigenlijk

Ik maak zelf veel gebruik van joins, heb nooit last van performance problemen

[vorlox]

WOW vet ...bedankt voor de tips over indexeren iedereen
klik....BAM klaar

[Verwijderd]

Hmm, maakt MySQL er zelf JOINS van Zie namelijk geen JOIN in jouw syntax staan... en waarom is de join syntax er dan eigenlijk

Ik maak zelf veel gebruik van joins, heb nooit last van performance problemen

Volgens mij is het functioneel gezien hetzelfde, alleen de syntax is anders. Ik werk veel met Oracle en Oracle voert de queries hetzelfde uit of nu wel of niet JOIN gebruikt. Zelf gebruik ik nooit de "JOIN syntax" en ik heb ook geen last van performance problemen. Ik denk dat het by MySQL ook wel zo werkt.

Performance problemen los ik op door m'n query anders te schrijven (indien mogelijk) of anders indexen toe te voegen op strategisch gekozen kolommen.

[ Voor 2% gewijzigd door Verwijderd op 14-05-2003 14:59 . Reden: typo ]

[Verwijderd]

vorlox schreef op 14 mei 2003 @ 14:52:
WOW vet ...bedankt voor de tips over indexeren iedereen
klik....BAM klaar

U vraagt, wij draaien

Indexen zijn HEEL belangrijk. Ze kunnen versnellen en vertragen, zie het stukje waar ik al eerder naar wees in de FAQ daarover.

[whoami]

[ash] schreef op 14 May 2003 @ 14:42:
[...]

Hmm, maakt MySQL er zelf JOINS van Zie namelijk geen JOIN in jouw syntax staan... en waarom is de join syntax er dan eigenlijk

Ik maak zelf veel gebruik van joins, heb nooit last van performance problemen

Een join is gewoon een 'link' die je legt tussen 2 tabellen.
Of je dat nu doet met de JOIN syntax of in de WHERE, dat maakt niet uit.

(En er zal ook geen verschil in performance zitten).

[bigtree]

whoami schreef op 14 mei 2003 @ 15:29:
[...]


Een join is gewoon een 'link' die je legt tussen 2 tabellen.
Of je dat nu doet met de JOIN syntax of in de WHERE, dat maakt niet uit.

(En er zal ook geen verschil in performance zitten).

Ik voel een benchmark aankomen...

[Verwijderd]

whoami schreef op 14 mei 2003 @ 15:29:
[...]


Een join is gewoon een 'link' die je legt tussen 2 tabellen.
Of je dat nu doet met de JOIN syntax of in de WHERE, dat maakt niet uit.

(En er zal ook geen verschil in performance zitten).

Voor zover ik weet zet de query engine van MySQL de join met = in het WHERE deel automatisch om in een LEFT JOIN. Iemand met MySQL kan de query misschien even laten analyseren om dat zeker te weten

Voor andere databases zou het weer anders kunnen liggen. Ik heb geen flauw idee wat MS SQL ermee doet, en binnen Oracle is het volgens mij juist de bedoeling dat je je JOINs in de WHERE maakt.

[bigtree]

Verwijderd schreef op 14 May 2003 @ 17:16:
[...]

Voor zover ik weet zet de query engine van MySQL de join met = in het WHERE deel automatisch om in een LEFT JOIN.

Je bedoelt waarschijnlijk INNER JOIN? Een left join haalt ook records uit de linker tabel op als er geen bijbehorende records uit de rechter tabel gevonden zijn.