Het maximale geheugengebruik van MySQL hangt sterk af van de hardware, uw instellingen en de database zelf.
Hardware
De hardware is het voor de hand liggende deel. Hoe meer RAM hoe beter, snellere schijven ftw . Geloof die maandelijkse of wekelijkse nieuwsbrieven echter niet. MySQL schaalt niet lineair - zelfs niet op Oracle-hardware. Het is een beetje lastiger dan dat.
Het komt erop neer:er is geen algemene vuistregel voor wat wordt aanbevolen voor uw MySQL-configuratie. Het hangt allemaal af van het huidige gebruik of de projecties.
Instellingen &database
MySQL biedt talloze variabelen en schakelaars om het gedrag te optimaliseren. Als je problemen tegenkomt, moet je echt gaan zitten en de (f'ing) handleiding lezen.
Wat betreft de database -- een paar belangrijke beperkingen:
- tabel-engine (
InnoDB,MyISAM, ...) - maat
- indexen
- gebruik
De meeste MySQL-tips over stackoverflow vertellen je over 5-8 zogenaamde belangrijke instellingen. Ten eerste zijn ze niet allemaal van belang - b.v. het toewijzen van veel middelen aan InnoDB en het niet gebruiken van InnoDB heeft niet veel zin omdat die middelen worden verspild.
Of - veel mensen stellen voor om de max_connection te verhogen variabele -- nou, ze weten niet dat het ook impliceert dat MySQL meer middelen zal toewijzen om die max_connections te verzorgen -- indien ooit nodig. De meer voor de hand liggende oplossing zou kunnen zijn om de databaseverbinding in uw DBAL te sluiten of om de wait_timeout te verlagen om die discussies vrij te maken.
Als je begrijpt wat ik bedoel -- er is echt heel veel om over te lezen en te leren.
Motoren
Table-engines zijn een vrij belangrijke beslissing, veel mensen vergeten die al vroeg en merken dan plotseling dat ze vechten met een MyISAM van 30 GB. tabel die hun hele applicatie vergrendelt en blokkeert.
Ik wil niet zeggen MyISAM zuigt , maar InnoDB kan worden aangepast om bijna of bijna net zo snel te reageren als MyISAM en biedt zoiets als rijvergrendeling op UPDATE terwijl MyISAM vergrendelt de hele tabel wanneer er naar wordt geschreven.
Als je de vrijheid hebt om MySQL op je eigen infrastructuur uit te voeren, kun je ook de percona-server
want naast veel bijdragen van bedrijven zoals Facebook en Google (ze weten snel), bevat het ook Percona's eigen drop-in vervanging voor InnoDB , genaamd XtraDB .
Zie mijn kern voor percona-server (en -client) setup (op Ubuntu):http://gist.github .com/637669
Maat
De grootte van de database is heel erg belangrijk -- geloof het of niet, de meeste mensen op de Intarwebs hebben nog nooit een grote en intense MySQL-setup gemaakt, maar die bestaan echt. Sommige mensen zullen trollen en iets zeggen als, "Gebruik PostgreSQL!!!111", maar laten we ze voor nu negeren.
Waar het op neerkomt is:afgaande op de grootte, moet er een beslissing worden genomen over de hardware. Je kunt een database van 80 GB niet echt snel laten werken op 1 GB RAM.
Indices
Het is niet:hoe meer, hoe beter. Alleen de benodigde indexen hoeven te worden ingesteld en het gebruik moet worden gecontroleerd met EXPLAIN . Voeg daaraan toe dat MySQL's EXPLAIN is echt beperkt, maar het is een begin.
Voorgestelde configuraties
Over deze my-large.cnf en my-medium.cnf bestanden -- ik weet niet eens voor wie die zijn geschreven. Rol er zelf een.
Tuning-primer
Een goed begin is de tuning primer
. Het is een bash-script (hint:je hebt linux nodig) dat de uitvoer van SHOW VARIABLES overneemt en SHOW STATUS en verpakt het in hopelijk nuttige aanbeveling. Als uw server enige tijd heeft gedraaid, is de aanbeveling beter omdat er gegevens zijn om ze op te baseren.
De tuning-primer is echter geen magische saus. Je moet nog steeds alle variabelen lezen die het voorstelt om te veranderen.
Lezen
Ik raad de mysqlperformanceblog echt aan . Het is een geweldige bron voor allerlei MySQL-gerelateerde tips. En het is niet alleen MySQL, ze weten ook veel over de juiste hardware of bevelen setups aan voor AWS, enz. Deze jongens hebben jarenlange ervaring.
Een andere geweldige bron is planet-mysql , natuurlijk.