We mogen het topic niet kapen, maar omdat dit ook de (suboptimale) performance van OpenCart raakt: je moet dan toch eens met EXPLAIN kijken naar het query execution plan.NOP Webdesign schreef:Dus niets mis met de SQL query, vraag gewoon veel info uit grote tabellen.
Ik heb een vergelijkbare tabel voor pageviews van 100 MB met een half miljoen records. (Ga ik over de 100 MB, dan gooi ik de oude data weg.) Deze tabel heeft twee VARCHAR-kolommen: remote_addr voor het IP-adres en remote_host voor de bijbehorende hostnaam.
De kolom remote_host heeft geen index.
Code: Selecteer alles
SELECT COUNT(*) AS pageviews
FROM pageview_statistics
GROUP BY remote_host
ORDER BY pageviews DESC
• 4.9012 s
• 3.7270 s
• 3.5874 s
Met jouw 200 MB en 1 miljoen records in plaats van mijn 100 MB en 0,5 miljoen records kun je bij benadering een verdubbeling verwachten: de eerder genoemde 10 seconde.
De kolom remote_addr heeft wél een index:
Code: Selecteer alles
SELECT COUNT(*) AS pageviews
FROM pageview_statistics
GROUP BY remote_addr
ORDER BY pageviews DESC
• 0.7584 s
• 0.5930 s
• 0.6655 s
Het punt is dat OpenCart op heel veel plaatsen géén INDEX heeft waar die wel gebruikt zou kunnen worden door de query optimizer van MySQL. Bij een FOREIGN KEY maakt MySQL automatisch een index, maar ook foreign keys zijn OpenCart vreemd: voor een JOIN over meerdere tabellen, moet dan een dubbele full table scan worden uitgevoerd met een subquery.
https://github.com/opencart/opencart/bl ... encart.sql
Tweede probleem dat je bij OpenCart kunt aanpakken is dat voor alle primaire sleutels een INT UNSIGNED wordt gebruikt. Dat maakt de keys in joins te groot: je hebt geen bijna 4,3 miljard klanten, 4,3 miljard adressen, 4,3 miljard categorieën, enzovoort, enzovoort. Het databaseontwerpbeginsel use the smallest key wordt dus met voeten getreden.