MySQL's maksimale hukommelsesforbrug afhænger meget af hardware, dine indstillinger og selve databasen.
Hardware
Hardwaren er den åbenlyse del. Jo mere RAM jo bedre, hurtigere diske ftw . Tro dog ikke på de månedlige eller ugentlige nyhedsbreve. MySQL skalerer ikke lineært - ikke engang på Oracle-hardware. Det er lidt vanskeligere end det.
Den nederste linje er:Der er ingen generel tommelfingerregel for, hvad der anbefales til din MySQL opsætning. Det hele afhænger af den aktuelle brug eller projektionerne.
Indstillinger og database
MySQL tilbyder utallige variabler og switches for at optimere dens adfærd. Hvis du løber ind i problemer, skal du virkelig sætte dig ned og læse (f'ing) manualen.
Hvad angår databasen -- et par vigtige begrænsninger:
- tabelmotor (
InnoDB,MyISAM, ...) - størrelse
- indekser
- brug
De fleste MySQL-tip om stackoverflow vil fortælle dig om 5-8 såkaldte vigtige indstillinger. For det første er det ikke alle, der betyder noget - f.eks. at allokere mange ressourcer til InnoDB og ikke bruge InnoDB giver ikke megen mening, fordi disse ressourcer er spildt.
Eller - mange mennesker foreslår at øge max_connection variabel -- godt, lidt ved de, det betyder også, at MySQL vil allokere flere ressourcer for at imødekomme disse max_connections - hvis det nogensinde er nødvendigt. Den mere oplagte løsning kan være at lukke databaseforbindelsen i din DBAL eller at sænke wait_timeout for at frigøre disse tråde.
Hvis du fanger min drift -- der er virkelig meget, meget at læse op på og lære.
Motorer
Bordmotorer er en ret vigtig beslutning, mange mennesker glemmer dem tidligt og pludselig kæmper med en MyISAM på 30 GB størrelse. tabel, som låser og blokerer hele deres applikation.
Jeg mener ikke at sige MyISAM stinker , men InnoDB kan justeres til at reagere næsten eller næsten lige så hurtigt som MyISAM og tilbyder sådan noget som rækkelåsning på UPDATE mens MyISAM låser hele tabellen, når den skrives til.
Hvis du er fri til at køre MySQL på din egen infrastruktur, kan du måske også tjekke percona-server
fordi blandt at inkludere en masse bidrag fra virksomheder som Facebook og Google (de ved det hurtigt), inkluderer det også Perconas egen drop-in erstatning for InnoDB , kaldet XtraDB .
Se mit indhold for opsætning af percona-server (og -klient) (på Ubuntu):http://gist.github .com/637669
Størrelse
Databasestørrelsen er meget, meget vigtig -- tro det eller ej, de fleste mennesker på Intarwebs har aldrig håndteret en stor og skriver intens MySQL-opsætning, men de eksisterer virkelig. Nogle mennesker vil trolde og sige noget som "Brug PostgreSQL!!!111", men lad os ignorere dem for nu.
Den nederste linje er:at dømme ud fra størrelsen, skal der træffes beslutning om hardwaren. Du kan ikke rigtig få en 80 GB database til at køre hurtigt på 1 GB RAM.
Indeks
Det er det ikke:jo flere, jo bedre. Kun nødvendige indekser skal indstilles, og brugen skal kontrolleres med EXPLAIN . Tilføj dertil MySQL's EXPLAIN er virkelig begrænset, men det er en begyndelse.
Foreslåede konfigurationer
Om disse my-large.cnf og my-medium.cnf filer -- jeg ved ikke engang, hvem de er skrevet til. Rul din egen.
Tuning primer
En god start er tuning-primeren
. Det er et bash-script (tip:du skal bruge linux), som tager outputtet fra SHOW VARIABLES og SHOW STATUS og pakker det ind i en forhåbentlig nyttig anbefaling. Hvis din server har kørt noget tid, vil anbefalingen være bedre, da der vil være data at basere dem på.
Tuning primeren er dog ikke en magisk sauce. Du bør stadig læse op på alle de variabler, det foreslår at ændre.
Læser
Jeg kan virkelig godt lide at anbefale mysqlperformanceblog . Det er en fantastisk ressource til alle slags MySQL-relaterede tips. Og det er ikke kun MySQL, de ved også meget om den rigtige hardware eller anbefaler opsætninger til AWS osv.. Disse fyre har mange års erfaring.
En anden stor ressource er planet-mysql selvfølgelig.