Sinds versie 3.22 kan MySQL standaard opstartopties voor de server en clients uit optiebestanden lezen. Op Unix worden de standaard MySQL-parameters gelezen uit de volgende bestanden:

DATADIR is een map MySQL-gegevens(meestal "/usr/local/mysql/data" voor een binaire installatie of "/usr/local/var" voor een installatie van bronteksten). Merk op dat dit de map is die is opgegeven tijdens de installatie, en niet degene die is opgegeven met –datadir bij het starten van mysqld! (–datadir heeft geen effect op de manier waarop parameterbestanden door de server worden bekeken, aangezien ze worden bekeken voordat de opdrachtregelargumenten worden verwerkt).

MySQL probeert de parameterbestanden in de hierboven vermelde volgorde te lezen. Als er meerdere van dergelijke bestanden zijn, heeft de parameter die is opgegeven in het bestand dat later komt, voorrang op dezelfde parameter die is opgegeven in het eerder geplaatste bestand. De parameters gespecificeerd in opdrachtregel, hebben een hogere prioriteit dan de parameters die zijn opgegeven in een van de parameterbestanden. Sommige parameters kunnen worden ingesteld met omgevingsvariabelen. Opties die zijn opgegeven op de opdrachtregel of in optiebestanden hebben voorrang op omgevingsvariabelen.

Hier is een lijst met programma's die parameterbestanden ondersteunen: mysql, mysqladmin, mysqld, mysqld_safe, mysql.server, mysqldump, mysqlimport, mysqlshow, mysqlcheck, myisamchk en myisampack.

Elke parameter die kan worden opgegeven op de opdrachtregel bij het uitvoeren van een MySQL-programma, kan ook worden opgegeven in het parameterbestand (zonder de voorafgaande dubbele slash). Om een ​​lijst met beschikbare opties te krijgen, voert u het programma uit met de optie –help.

My.cnf MySQL 5.5-parameters (UTF8-coderingen)

Wat is utf8mb4? utf8mb4 is een tekenset die wordt gebruikt om 4 bytes in MySQL op te slaan, geïntroduceerd in 2010 vanaf versie 5.5.3. Het belangrijkste verschil tussen utf8mb4 en utf8 is dat utf8mb4 meer gebruikt volledige mogelijkheden UTF8-codering, waardoor ondersteuning voor alle talen mogelijk is speciale karakters, die utf8 niet ondersteunen (bijvoorbeeld Japans of emoticons van ios - emoji). Maar zoals je misschien al vermoedt: als utf8mb4 4 bytes gebruikt om 1 teken op te slaan, kan de database groter worden vergeleken met exact dezelfde database in utf8. Tegenwoordig is een iets grotere databasegrootte geen groot probleem, dus als u voor de keuze staat tussen het gebruik van een utf8- of utf8mb4-tekenset, gebruik dan utf8mb4.

Sommige my.cnf-parameters in MySQL 5.5.22 zijn verouderd en vervangen en verwijderd. Het wijzigen van de standaardcodering in my.cnf in de sectie zou er bijvoorbeeld als volgt uitzien:

#... character_set_server = utf8 # voorheen standaard-character-set = utf8 en character_set_server = utf8 collation-server = utf8_unicode_ci # voorheen collation_server = utf8_unicode_ci

sorteerserver = utf8_unicode_ci of sorteerserver = utf8_general_ci? utf8_unicode_ci ondersteunt uitbreidingen, in tegenstelling tot utf8_general_ci, dat wil zeggen dat het één teken aan meerdere kan koppelen (bijvoorbeeld in Duitsland ß = ss). Meer zoals Unicode-tekensets.

Vergelijking utf8_unicode_ci _ci hoofdlettergevoelig, utf8_unicode_bin _bin hoofdlettergevoelig.

mijn.cnf-parameters

> ee /etc/my.cnf # De volgende opties worden doorgegeven aan alle MySQL-clients #password = jouw_wachtwoord poort = 3306 socket = /tmp/mysql.sock # Hier volgen de gegevens voor enkele specifieke programma's # De MySQL-serverpoort = 3306 socket = /tmp/mysql.sock skip-locking key_buffer_size = 16M max_allowed_packet = 1M table_open_cache = 64 sort_buffer_size = 512K net_buffer_length = 8K read_buffer_size = 256K read_rnd_buffer_size = 512K myisam_sort_buffer_size = 8M standaardkarakter -set = utf 8 karakter_set_server = utf8 collation_server = utf8_unicode_ci bindadres = 127.0.0.1 # Luister helemaal niet op een TCP/IP-poort. Dit kan een veiligheidsverbetering zijn, # als alle processen die verbinding moeten maken met mysqld op dezelfde host draaien. # Alle interactie met mysqld moet plaatsvinden via Unix-sockets of Named Pipes # Alle interactie met mysqld moet plaatsvinden via Unix-sockets of Named Pipes. # Merk op dat het gebruik van deze optie zonder het inschakelen van Named Pipes op Windows # (via de optie "enable-named-pipe) mysqld onbruikbaar zal maken. ! # #skip-netwerken #...

De standaardconfiguratieparameters in Mysql zijn ontworpen voor kleine databases die onder lage belasting draaien op zeer bescheiden hardware. Als uw plannen voor MySQL zich met enkele honderden records buiten de tabelgrenzen uitstrekken, zult u zeker de standaardinstellingen moeten wijzigen. Het proces voor het optimaal configureren van Mysql bestaat uit twee delen: initiële installatie en het aanpassen van parameters tijdens bedrijf. Het aanpassen van parameters in de bedrijfsmodus hangt grotendeels af van de specifieke kenmerken van uw systeem en de monitoring ervan - er zijn hier geen speciale regels. Voor instellingen starten Er zijn een aantal aanbevelingen:

MijnSQL - gratis systeem databasebeheer. Ontwikkeling en MySQL-ondersteuning wordt uitgevoerd door Oracle Corporation, die de rechten heeft ontvangen handelsmerk samen met het overgenomen Sun Microsystems, dat eerder had overgenomen Zweeds bedrijf MySQL AB. Het product wordt gedistribueerd onder zowel de GNU General Public License als zijn eigen commerciële licentie. Daarnaast creëren ontwikkelaars functionaliteit op maat gelicentieerde gebruikers, het is dankzij deze bestelling dat bijna het meest eerdere versies er verscheen een replicatiemechanisme.

Open het mysql-instellingenbestand, bijvoorbeeld:

/etc/mysql/mijn.cnf

De meest voorkomende parameters waar u op moet letten en die u moet wijzigen om aan uw vereisten te voldoen:

sleutel_buffer_grootte

Als u alleen MyIsam-tabellen gebruikt, stelt u deze waarde in op 30%...40% van alle beschikbare tabellen RAM op de server. MyIsam maakt gebruik van cache besturingssysteem voor gegevens, dus houd er rekening mee dat de overige vrij geheugen je hebt het precies hiervoor nodig. Als u weinig MyIsam-tabellen heeft en hun totale grootte klein is, laat deze waarde dan binnen 32 miljoen.

innodb_buffer_pool_size

Als u alleen InnoDB-tabellen gebruikt, stelt u deze waarde in op het maximaal mogelijke voor uw systeem. De InnoDB-buffer slaat zowel gegevens als indexen op in de cache (en de cache van het besturingssysteem wordt niet gebruikt), dus de waarde van deze sleutel moet worden ingesteld op 70%...80% van het beschikbare geheugen.

Als uw server op Linux of Unix draait, vergeet dan niet om de parameter innodb_flush_method in te stellen op “O_DIRECT” om caching op OS-niveau te voorkomen wat Mysql al in de cache opslaat.

innodb_log_file_size

Let op deze parameter als u een groot aantal records heeft. Hoe groter formaat deze sleutel, hoe efficiënter de gegevensregistratie zal zijn. Maar houd er rekening mee dat dit de systeemhersteltijd zal verlengen! Deze parameter wordt doorgaans ingesteld op 64M-512M.

innodb_flush_log_at_trx_commit

Deze parameter heeft een aanzienlijke invloed op de snelheid van werken (schrijven) van innoDB-tabellen.
De waarde “1″ betekent dat elke voltooide transactie het logboek synchroon naar schijf zal wissen.
De waarde “2″ doet hetzelfde, alleen wordt het logboek niet naar de schijf gedumpt, maar naar de cache van het besturingssysteem. Deze waarde is in de meeste gevallen geschikt, omdat... voert geen dure schrijfbewerking uit na elke transactie. In dit geval wordt het logboek met een vertraging van enkele seconden naar schijf geschreven, wat vanuit het oogpunt van gegevensveiligheid zeer veilig is.
Een waarde van “0” zal opleveren hoogste productiviteit. In dit geval wordt de buffer ongeacht de transacties naar het logbestand geleegd. Stel deze parameter op eigen risico in op “0”, omdat in dit geval neemt het risico op gegevensverlies toe.

tabel_cache

Deze sleutel bepaalt het geheugen dat is toegewezen voor opslag open tafels. Als u enkele honderden tabellen heeft, stelt u deze waarde in op 1024. Als u een groot aantal verbindingen heeft, verhoogt u deze waarde geleidelijk, omdat Voor elke verbinding wordt een afzonderlijk record opgeslagen.

thread_cache

Deze parameter helpt bij het voorkomen van het maken/vernietigen van threads bij het verbinden met de server. Stel deze parameter in op 16 en verhoog deze indien nodig. Controleer de indicator “Threads_created”, idealiter zou deze gelijk moeten zijn aan nul:

Mysql> toon status zoals 'threads_created'; +-----–+--–+ | Variabele_naam | Waarde | +-----–+--–+ | Threads_created | 423312 | +-----–+--–+

query_cache_grootte

De waarde van deze parameter bepaalt hoeveel geheugen er moet worden gebruikt voor de querycache. Laat u niet meeslepen door het instellen van enorme waarden. De querycache mag niet groot zijn, omdat... mysql zal bronnen opslokken voor het beheren van gegevens in de cache. Begin met 32M...128M en verhoog indien nodig.

10 augustus 2009 om 15:41 uur

Wat moet er direct na installatie in mySQL worden geconfigureerd?

• MySQL

• Vertaling

Gratis vertaling van een vrij oud artikel uit de MySQL Performance Blog over wat je het beste direct na installatie kunt configureren basisversie mySQL.

Het is verbazingwekkend hoeveel mensen mySQL op hun servers installeren en de standaardinstellingen behouden.

Hoewel er nogal wat instellingen in mySQL zijn die je kunt wijzigen, zijn er een aantal heel erg belangrijke kenmerken, waarvoor geoptimaliseerd moet worden eigen server. Meestal hierna kleine instellingen De serverprestaties nemen merkbaar toe.

• sleutel_buffer_grootte- extreem belangrijke instelling bij gebruik van MyISAM-tabellen. Stel dit in op ongeveer 30-40% van het beschikbare RAM-geheugen als u alleen MyISAM gebruikt. Juiste maat hangt af van de grootte van de indexen, de gegevens en de belasting van de server - onthoud dat MyISAM de cache van het besturingssysteem (OS) gebruikt om de gegevens op te slaan, dus u moet voldoende RAM-ruimte overhouden voor de gegevens, en de gegevens kunnen nemen aanzienlijk meer ruimte in beslag dan de indexen. Zorg er echter voor dat u controleert of alle ruimte is toegewezen door de richtlijn sleutel_buffer_grootte voor cache, werd constant gebruikt - je kunt echter vaak situaties zien waarin 4 GB wordt toegewezen voor de indexcache totale grootte Alle .MYI-bestanden zijn niet groter dan 1 GB. Dit doen is volkomen nutteloos; je verspilt alleen maar hulpbronnen. Als u vrijwel geen MyISAM-tabellen heeft, dan sleutel_buffer_grootte moet worden ingesteld op ongeveer 16-32 MB - ze zullen worden gebruikt om indexen van tijdelijke tabellen die op schijf zijn gemaakt, in het geheugen op te slaan.
• innodb_buffer_pool_size- een even belangrijke instelling, maar let er voor InnoDB op als u voornamelijk InnoDB-tabellen gaat gebruiken, want ze zijn veel gevoeliger voor de buffergrootte dan MyISAM-tabellen. MyISAM-tabellen kunnen in principe zelfs goed werken met een groot aantal gegevens en tegen standaardwaarde sleutel_buffer_grootte, mySQL kan echter erg traag zijn als de waarde onjuist is innodb_buffer_pool_size. InnoDB gebruikt zijn eigen buffer om zowel indexen als gegevens op te slaan, dus er is geen noodzaak om geheugen over te laten voor de cache van het besturingssysteem - installeren innodb_buffer_pool_size in 70-80% van het beschikbare RAM (als er natuurlijk alleen InnoDB-tabellen worden gebruikt). Relatief maximale grootte deze optie - vergelijkbaar sleutel_buffer_grootte- laat je niet meeslepen, je moet vinden optimale maat, vinden beste gebruik beschikbaar geheugen.
• innodb_additional_mem_pool_size - deze optie heeft vrijwel geen effect op de prestaties van mySQL, maar ik raad aan om ongeveer 20 MB (of iets meer) over te laten voor InnoDB voor verschillende interne behoeften.
• innodb_log_file_size- een uiterst belangrijke instelling in databaseomgevingen met frequente operaties records in tabellen, vooral wanneer grote volumes. B O Grotere formaten verhogen de prestaties, maar wees voorzichtig: de gegevenshersteltijd zal ook toenemen. Ik stel het meestal in op ongeveer 64-512 MB, afhankelijk van de servergrootte.
• innodb_log_buffer_size - standaard waarde Deze optie is redelijk geschikt voor de meeste systemen met een gemiddeld aantal schrijfbewerkingen en kleine transacties. Als uw systeem veel activiteit ervaart, of als u actief met BLOB-gegevens werkt, raad ik u aan de waarde iets te verhogen innodb_log_buffer_size. Overdrijf het echter niet: te veel grote waarde zou geheugenverspilling zijn: de buffer wordt elke seconde leeggemaakt, dus je hebt tijdens die seconde niet meer ruimte nodig dan nodig is. De aanbevolen waarde is ongeveer 8-16 MB, en voor kleine databases zelfs nog minder.
• - klagen dat InnoDB 100 keer langzamer is dan MyISAM? Waarschijnlijk ben je de instelling vergeten innodb_flush_log_at_trx_commit. De standaardwaarde 1 betekent dat elke UPDATE-transactie (of soortgelijke niet-transactionele opdracht) de buffer naar schijf moet leegmaken, wat behoorlijk veel hulpbronnen vergt. De meeste applicaties, vooral applicaties die eerder MyISAM-tabellen hebben gebruikt, zullen goed werken met een waarde van "2" (dat wil zeggen "de buffer niet naar schijf leegmaken, alleen naar de cache van het besturingssysteem"). Het logboek wordt echter nog steeds elke 1-2 seconden naar schijf gewist, dus bij een ongeval verliest u maximaal 1-2 seconden aan updates. Een waarde van "0" verbetert de prestaties, maar u loopt het risico gegevens te verliezen, zelfs als de MySQL-server crasht, terwijl u de waarde instelt op innodb_flush_log_at_trx_commit in “2” verlies je alleen gegevens als het hele besturingssysteem crasht.
• tabel_cache- het openen van tafels kan behoorlijk veel middelen vergen. MyISAM-tabellen markeren bijvoorbeeld de headers van .MYI-bestanden als "gebruikt in huidige moment" Het is over het algemeen geen goed idee om tafels te vaak te openen, dus het is het beste om een ​​cache te hebben die groot genoeg is om al uw tafels open te houden. Dit gebruikt wat OS-bronnen en RAM, maar dit is meestal geen groot probleem moderne servers. Als u enkele honderden tabellen heeft, dan is de startwaarde voor de optie tabel_cache kan "1024" zijn (onthoud dat elke verbinding een eigen handle nodig heeft). Als je dat nog hebt meer tafels of te veel verbindingen - verhoog de parameterwaarde. Ik zag mySQL-servers met betekenis tabel_cache gelijk aan 100.000.
• thread_cache- het maken/vernietigen van threads is ook een resource-intensieve operatie die plaatsvindt telkens wanneer een verbinding tot stand wordt gebracht en elke verbinding wordt verbroken. Meestal stel ik deze optie in op 16. Als uw toepassing mogelijk sprongen heeft in het aantal gelijktijdige verbindingen en per variabele Onderwerpen_aangemaakt Als u een snelle toename van het aantal threads ziet, moet u de waarde verhogen thread_cache. Het doel is om te voorkomen dat er nieuwe threads worden aangemaakt tijdens normaal gebruik van de server.
• query_cache_grootte- als uw applicatie veel en frequent gegevens leest, en u niet over een cache op applicatieniveau beschikt, kan deze optie zeer nuttig zijn. Stel deze waarde niet te hoog in, omdat het onderhouden van een grote querycache op zichzelf duur zal zijn. De aanbevolen waarde ligt tussen 32 en 512 MB. Vergeet niet te controleren hoe goed de querycache wordt gebruikt - onder bepaalde omstandigheden (met een klein aantal hits in de cache, dat wil zeggen wanneer er bijna geen identieke gegevens worden opgehaald) kan het gebruik van een grote cache de prestaties verslechteren.

Zoals je kunt zien is dit - globale instellingen. Deze variabelen zijn afhankelijk van de serverhardware en de gebruikte MySQL-engines, terwijl sessievariabelen meestal specifiek hiervoor worden geconfigureerd specifieke taken. Als je voornamelijk gebruikt eenvoudige vragen, dan is het niet nodig om de waarde te verhogen sort_buffer_grootte, zelfs als je 64 GB RAM extra hebt. Bovendien kunnen grote cachewaarden de serverprestaties alleen maar verslechteren. Het is beter om sessievariabelen voor later te bewaren, voor het verfijnen van de server.

PS: de mySQL-installatie wordt geleverd met verschillende vooraf geïnstalleerde my.cnf-bestanden die zijn ontworpen voor verschillende lading. Als u geen tijd heeft om de server handmatig te configureren, is het meestal beter om deze te gebruiken dan de standaardserver configuratiebestand, waarbij u degene kiest die het meest geschikt is voor de belasting van uw server.

Het instellen van MySQL omvat feitelijk het bewerken van het hoofdconfiguratiebestand (/etc/my.cnf op FreeBSD). Houd er vóór het instellen rekening mee dat in MySQL 5.6 de namen van sommige parameters en hun beschikbaarheid verschillen van die in eerdere versies.

MySQL 5.6 - my.cnf configureren

Om de wijzigingen in het bestand my.cnf van kracht te laten worden, moet u de MySQL-server opnieuw opstarten:

/usr/local/etc/rc.d/mysqld opnieuw opstarten

Via een databasequery kunt u controleren of de nieuwe instellingen door de server worden geaccepteerd:

mysql> WAARBAARDEN TONEN;

Om alleen bepaalde instellingen te bekijken, moet u het verzoek specificeren. Om bijvoorbeeld de parameter max_connections te zien, moet u het volgende verzoek naar MySQL sturen: mysql > TOON VARIABELEN ZOALS "max _conn%";

Als de wijzigingen na een herstart gedeeltelijk worden toegepast of niet worden geaccepteerd door de MySQL-server, controleer dan of het verkeerde bestand mogelijk is bewerkt of dat MySQL bovendien een ander configuratiebestand laadt, waarvan de richtlijnen de door u gewijzigde parameters opnieuw toewijzen. Wanneer u bijvoorbeeld het DirectAdmin hosting controlepaneel installeert, wordt de MySQL-server automatisch geïnstalleerd en bevat deze 2 configuratiebestanden: /etc/my.cnf en een extra geladen /usr/local/mysql/my.cnf. Door de parameter sql_mode in /etc/my.cnf te veranderen, kon ik lange tijd niet begrijpen waarom deze niet werd toegepast op de MySQL-server, deze werd overschreven in /usr/local/mysql/my.cnf ( FreeBSD) of /usr/my. Hoe u een lijst kunt vinden met alle my.cnf-bestanden die in MySQL worden gebruikt, kunt u bekijken door een zoekopdracht in te voeren zoekmachine: "mijn.cnf-locatie".

De volledige lijst met instellingen die in my.cnf worden gebruikt, is te vinden in de officiële MySQL-gebruikershandleiding (eng), in de kolom Optiebestand.

Instellingen in de sectie

lokaal_inbestand

Deze variabele kan worden ingeschakeld (AAN of 1 - standaard) of uitgeschakeld (UIT of 0) om LOCAL te gebruiken in een LOAD DATA-verzoek. Als u niet precies weet wat het is en waarom het nodig is, wordt het ten zeerste aanbevolen om local_infile op OFF (local_infile=OFF) te zetten vanwege veiligheidsredenen voor de server als geheel.

skip_external_locking

skip_external_locking - parameter die verantwoordelijk is voor de externe vergrendeling van databasebestanden van het MyISAM-type (standaard ingesteld op AAN - vergrendeling is ingeschakeld). Om prestatieredenen van de MySQL-server wordt aanbevolen deze instelling niet te wijzigen.

skip_name_resolve

Als de parameter skip_name_resolve is ingesteld op ON of 1 (skip_name_resolve=OFF - standaard), dan externe verbinding De MySQL-server probeert de domeinnaam te vertalen naar een IP-adres, wat de snelheid van de aanvraagverwerking aanzienlijk vermindert. Om de prestaties te verbeteren, wordt aanbevolen om skip_name_resolve op OFF in te stellen, in dit geval kan alleen het IP-adres of de localhost als host worden gebruikt bij het verbinden met MySQL.

lage_prioriteit_updates

Standaard hebben MySQL-instructies zoals INSERT, REPLACE, UPDATE, DELETE meer hoge prioriteit dan bijvoorbeeld SELECT, en de parameter low_priority_updates wordt overeenkomstig ingesteld op OFF. Als uw server meer leesverzoeken verzendt dan wijzigingen in tabelgegevens, kunt u low_priority_updates instellen op ON. Opgemerkt moet worden dat low_priority_updates alleen van toepassing is op de tabeltypen MyISAM, MEMORY en MERGE.

sql_modus

De werking van de MySQL-server is sterk afhankelijk van de parameters die zijn opgegeven in sql_mode. Onjuiste specificatie van instellingen kan de werking van een site die MySQL gebruikt volledig stopzetten, leiden tot het invoegen van onjuiste parameters in de database en andere problemen. U kunt hier meer lezen over sql_mod: Server SQL Modes 5.6 (eng).

Standaard in MySQL 5.6.6 en hoger latere versies sql_mode waarde is ingesteld op NO_ENGINE_SUBSTITUTION ( sql_mode=NO_ENGINE_SUBSTITUTION), wat voor de meeste sites voldoende zal zijn, maar nog steeds begrijpelijk MySQL-werk U moet ook op de hoogte zijn van andere manieren waarop MySQL werkt, ingesteld in sql_mode.

max_verbindingen

Deze parameter is verantwoordelijk voor het maximaal toegestane aantal gelijktijdige verbindingen naar MySQL. De standaardwaarde is 151 en kan worden gewijzigd van 1 in 100.000. Deze waarde moet worden verhoogd als de foutmelding 'Te veel verbindingen' verschijnt of als de beheerder er zeker van is dat de standaardwaarde niet voldoende zal zijn.

query_cache_type

Met de waarde query_cache_type wordt het cachen van query's ingeschakeld (AAN) of uitgeschakeld (UIT). Caching - goede manier verminder de belasting als de server veel identieke verzoeken verwerkt. U moet bijna altijd query_cache_type gebruiken, behalve wanneer MySQL-query's in de cache worden opgeslagen door memcached.

query_cache_grootte

Cachegrootte MySQL-query's. De waarde kan worden geschreven in Mb - query_cache_size=32M .

Instellingen voor MyISAM-tabellen

sleutel_buffer_grootte

Als er alleen tabellen worden gebruikt MijnISAM, moet de buffergrootte worden ingesteld op ongeveer 30-35% van de beschikbare RAM-grootte. Als er heel weinig MyISAM-tabellen zijn of helemaal geen tabellen, dan sleutel_buffer_grootte kan worden ingesteld op 32 MB, de ruimte wordt gebruikt voor het opslaan van indexen in het geheugen van tijdelijke tabellen die op schijf zijn gemaakt. De keuze van de geheugengrootte voor key_buffer_size hangt af van de grootte van de indexen, gegevens en serverbelasting. U moet weten dat MyISAM de cache van het besturingssysteem gebruikt om daar gegevens op te slaan, dus u moet er voldoende RAM-ruimte voor overhouden. Gegevens kunnen aanzienlijk meer ruimte in beslag nemen dan indexen. Het is echter de moeite waard om te controleren of al het geheugen dat is opgegeven in key_buffer_size voor de cache voortdurend in gebruik is, anders is het een verspilling van bronnen.

Instellingen voor InnoDB-tabellen

innodb_buffer_pool_size

innodb_buffer_pool_size- buffergrootte van InnoDB-tabellen. Typ tabellen InnoDB gebruiken hun eigen buffer om indexen en gegevens op te slaan, dus het is niet nodig om geheugen over te laten voor de cache van het besturingssysteem; stel innodb_buffer_pool_size in op 75% van het beschikbare RAM als u van plan bent alleen tabellen met het InnoDB-type te gebruiken. Aanbevelingen voor de maximale grootte van deze optie zijn vergelijkbaar met key_buffer_size voor MyISAM: u moet de maximale grootte niet instellen, u moet deze vinden beste optie, A beschikbaar RAM-geheugen kan ook voor andere taken worden gebruikt.

• Vertaling

Een gratis vertaling van een vrij oud artikel uit de MySQL Performance Blog over wat je het beste kunt configureren direct na het installeren van de basisversie van mySQL.

Het is verbazingwekkend hoeveel mensen mySQL op hun servers installeren en de standaardinstellingen behouden.

Ondanks het feit dat er in mySQL nogal wat instellingen zijn die je kunt wijzigen, is er een aantal echt heel belangrijke kenmerken die geoptimaliseerd moeten worden voor je eigen server. Meestal nemen de serverprestaties na zulke kleine aanpassingen merkbaar toe.

• sleutel_buffer_grootte- een uiterst belangrijke instelling bij het gebruik van MyISAM-tabellen. Stel dit in op ongeveer 30-40% van het beschikbare RAM-geheugen als u alleen MyISAM gebruikt. De juiste grootte hangt af van de grootte van de indexen, de gegevens en de belasting van de server. Houd er rekening mee dat MyISAM de cache van het besturingssysteem (OS) gebruikt om de gegevens op te slaan, dus u moet voldoende RAM-ruimte overhouden voor de gegevens, en de gegevens kunnen aanzienlijk meer ruimte in beslag nemen dan de indexen. Zorg er echter voor dat u controleert of alle ruimte is toegewezen door de richtlijn sleutel_buffer_grootte voor cache, werd constant gebruikt - je kunt vaak situaties zien waarin 4 GB wordt toegewezen voor de indexcache, hoewel de totale grootte van alle .MYI-bestanden niet groter is dan 1 GB. Dit doen is volkomen nutteloos; je verspilt alleen maar hulpbronnen. Als u vrijwel geen MyISAM-tabellen heeft, dan sleutel_buffer_grootte moet worden ingesteld op ongeveer 16-32 MB - ze zullen worden gebruikt om indexen van tijdelijke tabellen die op schijf zijn gemaakt, in het geheugen op te slaan.
• innodb_buffer_pool_size- een even belangrijke instelling, maar let er voor InnoDB op als u voornamelijk InnoDB-tabellen gaat gebruiken, want ze zijn veel gevoeliger voor de buffergrootte dan MyISAM-tabellen. MyISAM-tabellen kunnen in principe goed werken, zelfs met een grote hoeveelheid gegevens en met de standaardwaarde sleutel_buffer_grootte, mySQL kan echter erg traag zijn als de waarde onjuist is innodb_buffer_pool_size. InnoDB gebruikt zijn eigen buffer om zowel indexen als gegevens op te slaan, dus er is geen noodzaak om geheugen over te laten voor de cache van het besturingssysteem - installeren innodb_buffer_pool_size in 70-80% van het beschikbare RAM (als er natuurlijk alleen InnoDB-tabellen worden gebruikt). Wat betreft de maximale grootte van deze optie - op dezelfde manier sleutel_buffer_grootte- laat je niet meeslepen, je moet de optimale grootte vinden, het beste gebruik van het beschikbare geheugen vinden.
• innodb_additional_mem_pool_size- deze optie heeft vrijwel geen effect op de prestaties van mySQL, maar ik raad aan om ongeveer 20 MB (of iets meer) over te laten voor InnoDB voor verschillende interne behoeften.
• innodb_log_file_size- een uiterst belangrijke instelling in databases met frequente schrijfbewerkingen naar tabellen, vooral bij grote volumes. B O Grotere formaten verhogen de prestaties, maar wees voorzichtig: de gegevenshersteltijd zal ook toenemen. Ik stel het meestal in op ongeveer 64-512 MB, afhankelijk van de servergrootte.
• innodb_log_buffer_size- de standaardwaarde van deze optie is redelijk geschikt voor de meeste systemen met een gemiddeld aantal schrijfbewerkingen en kleine transacties. Als uw systeem veel activiteit ervaart, of als u actief met BLOB-gegevens werkt, raad ik u aan de waarde iets te verhogen innodb_log_buffer_size. Overdrijf het echter niet: een te grote waarde is geheugenverspilling: de buffer wordt elke seconde leeggemaakt, dus je hebt gedurende die seconde niet meer ruimte nodig dan nodig is. De aanbevolen waarde is ongeveer 8-16 MB, en voor kleine databases zelfs nog minder.
• - klagen dat InnoDB 100 keer langzamer is dan MyISAM? Waarschijnlijk ben je de instelling vergeten innodb_flush_log_at_trx_commit. De standaardwaarde 1 betekent dat elke UPDATE-transactie (of soortgelijke niet-transactionele opdracht) de buffer naar schijf moet leegmaken, wat behoorlijk veel hulpbronnen vergt. De meeste applicaties, vooral applicaties die eerder MyISAM-tabellen hebben gebruikt, zullen goed werken met een waarde van "2" (dat wil zeggen "de buffer niet naar schijf leegmaken, alleen naar de cache van het besturingssysteem"). Het logboek wordt echter nog steeds elke 1-2 seconden naar schijf gewist, dus bij een ongeval verliest u maximaal 1-2 seconden aan updates. Een waarde van "0" verbetert de prestaties, maar u loopt het risico gegevens te verliezen, zelfs als de MySQL-server crasht, terwijl u de waarde instelt op innodb_flush_log_at_trx_commit in “2” verlies je alleen gegevens als het hele besturingssysteem crasht.
• tabel_cache- het openen van tafels kan behoorlijk veel middelen vergen. MyISAM-tabellen markeren de headers van .MYI-bestanden bijvoorbeeld als 'momenteel in gebruik'. Het is over het algemeen geen goed idee om tafels te vaak te openen, dus het is het beste om een ​​cache te hebben die groot genoeg is om al uw tafels open te houden. Dit gebruikt wat OS-bronnen en RAM, maar dit is meestal geen groot probleem op moderne servers. Als u enkele honderden tabellen heeft, dan is de startwaarde voor de optie tabel_cache kan "1024" zijn (onthoud dat elke verbinding een eigen handle nodig heeft). Als u nog meer tabellen of veel verbindingen heeft, verhoogt u de waarde van de parameter. Ik zag een mySQL-server met de waarde tabel_cache gelijk aan 100.000.
• thread_cache- het maken/vernietigen van threads is ook een resource-intensieve operatie die plaatsvindt telkens wanneer een verbinding tot stand wordt gebracht en elke verbinding wordt verbroken. Meestal stel ik deze optie in op 16. Als uw toepassing mogelijk sprongen heeft in het aantal gelijktijdige verbindingen en per variabele Onderwerpen_aangemaakt Als u een snelle toename van het aantal threads ziet, moet u de waarde verhogen thread_cache. Het doel is om te voorkomen dat er nieuwe threads worden aangemaakt tijdens normaal gebruik van de server.
• query_cache_grootte- als uw applicatie veel en frequent gegevens leest, en u niet over een cache op applicatieniveau beschikt, kan deze optie zeer nuttig zijn. Stel deze waarde niet te hoog in, omdat het onderhouden van een grote querycache op zichzelf duur zal zijn. De aanbevolen waarde ligt tussen 32 en 512 MB. Vergeet niet te controleren hoe goed de querycache wordt gebruikt - onder bepaalde omstandigheden (met een klein aantal hits in de cache, dat wil zeggen wanneer er bijna geen identieke gegevens worden opgehaald) kan het gebruik van een grote cache de prestaties verslechteren.

Zoals u kunt zien, zijn dit globale instellingen. Deze variabelen zijn afhankelijk van de serverhardware en de gebruikte MySQL-engines, terwijl sessievariabelen meestal specifiek voor specifieke taken worden geconfigureerd. Als u voornamelijk eenvoudige query's gebruikt, hoeft u de waarde niet te verhogen sort_buffer_grootte, zelfs als je 64 GB RAM extra hebt. Bovendien kunnen grote cachewaarden de serverprestaties alleen maar verslechteren. Het is beter om sessievariabelen voor later te bewaren, voor het verfijnen van de server.

PS: de mySQL-installatie wordt geleverd met verschillende vooraf geïnstalleerde my.cnf-bestanden, ontworpen voor verschillende belastingen. Als u geen tijd heeft om de server handmatig te configureren, is het meestal beter om deze te gebruiken dan het standaardconfiguratiebestand, waarbij u het bestand kiest dat het meest geschikt is voor de belasting van uw server.