MySQL Optimisering.

Hej, har en databas på 3 miljoner rows, och problemet är att det går så jävla segt att söka i den, har sökt men inte hittat nåt vettigt som funkar för å speeda upp den, så nu undrar jag om det finns nån här som har bra tips för hur jag ska få det att gå snabbare(har root access till burken så kan ändra inställningar i själva mysql om så behövs.).

Databasen körs på MySQL 5.0.24a i linux.
Servern den ligger på är en AMD ATHLON XP 2800+ med 1gb minne.

Tack på förhand.

Lite generella tips som kanske nån kan översätta till MySQL.

1. Index. Sätt index på de fält (fältkombinationer) som du söker på.


2. Sammanställ till nya tabeller såna frågor som är vanliga.

Ett exempel:

Om du har en tabell med följande fält:
RadId, Kundid, Vara, Datum, Belopp

Och det ofta frågas på vad en viss kund handlat för, så kan du varje natt sammanställa summor till en tabell som ser ut så här:
Kundid, Belopp

(Det förutsätter att du har möjlighet till att köra frågor via schema, vilket jag ju inte vet om det finns i MySql)

Ok tack för tipset, alternativ 2 är dock inte möjligt p.g.a vad databasen används till, men ska ta en titt på index

Håller med Ruskigbuss om index, det brukar vara en bra väg till bättre prestanda. Tänk på att ett index snabbar upp sökningar, men ökar samtidigt kostnaden för att lägga till nya rader eftersom indexet måste uppdateras. Det är en fråga om balansering men ofta en nettovinst eftersom sökningar är det som tar tid.

Nu kan jag inte MySQL, men MS SQL har verktyg där man kan titta på databasmotorns "execution plan" för ett script, och se vad det är som tar tid. Ofta hittar man sätt att "vända på" nästade selects, joins och liknande för att snabba upp rejält.

En annan fråga, är primärnyckeln vettig? Finns det ens nån primärnyckel? (Om jag inte minns fel så dikterar det även hur datan ligger på disk, och det påverkar ju i högsta grad sökprestanda.)

nu gjorde du mig lite nyfiken. vågar man fråga vad det är för nån site som har en db med 3milj rows?

Är alla raderna relevanta? Om de flesta sökningarna endast gäller rader som lagts till den senaste veckan, månaden eller året så kan det vara klokt att skapa tabeller (varje natt?) med endast relevant data för de vanligaste sökningarna. Annars är index och optimering av SQL-satsen som tidigare nämnts bra att lära sig använda.

Om du kan posta SQL-koden för utsökningen och hur tabellen ser ut så kanske man kan ge ett mer konkret tips.

Lycka till,
/S

Som alla skriver, använd index korrekt. Om du använder index blir det en logaritmisk sökning istället för en linjär sökning - åtminstone rent teoretiskt. Så ponera att vi har 3 000 000 rader i databasen. Om man söker logaritmiskt behöver man endast gå igenom cirka 22 element, men linjärt behöver man gå igenom alla 3 000 000. Detta är som sagt rent teoretiskt och det ser väl inte riktigt ut så här då datan ligger på disk och man hämtar lite större block i taget. Däremot så förstår man att det är stor skillnad på att ha index och att inte ha index.

Det finns ett direktiv i MySQL 5 där man kan logga alla förfrågningar som inte använder index. Dessa loggas till slow log-filen. Om du vill göra detta, lägger du till följande i din MySQL-conf.

En sak som jag alltid brukar göra när jag skriver querys är att använda EXPLAIN på dessa. Då ser man om frågan använder index korrekt. När du sedan kollar i loggen för frågor som inte använder index, använder du också EXPLAIN på dessa.

Jag har det. En av de produkter som vi säljer ska det samlas in och sparas mättdata från produktionstester som görs hos underleverantörer.
Vi säljer mellan 1-1.5 miljoner av denna produkt årligen. Enough said.

Index brukar göra susen när man brukar söka på något som inte är deklarerat som PK/FK, ex namn, ort mm

PK/FK är index.